-
Notifications
You must be signed in to change notification settings - Fork 1.2k
hooks: pylint: pre-commit failure #4145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@casperdcl, as pre-commit runs on an isolated environment, we'd need to disable a lot of configuration to do this way. Also, contributors should already install from
Is it too difficult to |
For now I'm fine with popping off from the pre-commit hooks as you suggest; this seems far less painful than leaving it as-is. |
@casperdcl We still need to Do I understand correctly that you guys are discussing removing pylint from pre-commit hooks? I'm strongly against that, it is helping to discover issues before creating a PR and is certainly faster than waiting for CI to error-out. |
@efiop, I'm still looking for answer for "Is it too difficult to pip install .[tests]?" from @casperdcl. If it's too hard to install our test dependencies, I could create a custom script that just throws a message to the user |
@skshetry @casperdcl why does pylint is different in this sense from black, isort and other "linters"? (just curious where does this problem come from). They should be the same to mind, have the same flow, conventions, etc. |
@shcheklein, pylint also does dynamic analysis for some checks, not just static analysis. You can see some failures here: https://github.com/iterative/dvc/pull/4146/checks?check_run_id=827566035#step:5:124 When in isolated environment, not all dependencies are installed and Also, we are using a plugin So, TLDR: it does dynamic execution too, and is hence able to find more issues. |
@skshetry gotcha, makes sense! I would vote probably for providing some happy path in simple scenarios (warn but do not fail if env is not fully setup), assuming we always run it on CI/CD. |
"Difficult" is not really the adjective I'd use... but for a casual newcomer, yes. It would be a complication that would be difficult and off-putting. Personally I'd say "nuisance" and "incorrect" rather than "difficult" (see below)
This is the point. It's not really a linter. It's really more of a full-blown test suite.
|
exactly. |
this is a good point, btw. I would say that even existing DVC hook (dvc status?) is quite annoying already when you develop fast and do commits. |
So looks like nothing to do here? Or am I missing something? For the record: if you want to disable the hooks just use --no-verify. |
@efiop I think the consensus between (@shcheklein, @skshetry, and I) is to either remove or allow failures of the hook in pre-commit (but leave it in CI).
As I understand, @efiop is against this idea because:
However, the same could be said of every single non-authenticated CI/CD test. It is also not a fast test, it takes a few seconds so really shouldn't happen pre-commit. Using
|
I feel like we are mixing up topics here. The original issue is The second issue that came up is pylint not being very fast (and, well, the whole pre-commit set of hooks). I can't see any way of making it significantly less intrusive without defeating the purpose of having pre-commit hooks in the first place. I would say that the slowest in the pack is our dvc hook itself, so probarly would start there (it was the intention so we eat our own food). |
Not sure about the "DVC hook taking the longest" though - on my machine pylint it much slower; maybe that's just me. |
I don't like that approach/hack, it's far easier to pre-activate virtualenv. And, it does not solve the issue, it still needs The possible ways to solve this are:
I don't have any strong opinions on either of the above. cc @casperdcl @efiop |
I was thinking about option (2) as well; sounds reasonable? |
Noop is too dangerous, people will just ignore it. Could try to improve the message, but I'm not sure if it could help much, since it is descriptive already. If not that and there is no better option, I would just leave it as is for now. |
I think no-op would be frustrating for contributors -> silent pass just to fail on PR, each time we have new python env. |
Ok, so looks like "do nothing" is the choice for now. Closing. |
Uh oh!
There was an error while loading. Please reload this page.
.pre-commit-config.yaml
states that thepylint
hook is defined locally, yet.pre-commit-hooks.yaml
fails to define it. As a result, attempting to commit will result in an error:Defining the hook's language as
system
and asking devs to manually runpip install .[tests]
goes against fundamental principles of pre-commit hooks. None of the other hooks require this.In any case
pylint
itself defines.pre-commit-hooks.yaml
so we should just use theirs.The text was updated successfully, but these errors were encountered: