-
-
Notifications
You must be signed in to change notification settings - Fork 308
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
exclude
setting doesn't work when passing full path
#72
Comments
In GitLab by @sigmavirus24 on Jan 23, 2015, 19:38 This expected and encouraged behaviour. The use case where someone explicitly does In the case of an entire directory, this is impractical and wrong. As a compromise passing the file will ignore the exclude directive assuming the user actually wants to lint that file. |
In GitLab by @arufuredosan on Jan 24, 2015, 06:10 The "impractical and wrong" case is not documented as such and the behavior is now relied upon for other tools that consume There is also nothing in the documentation that clearly states that this behavior should be expected (e.g. "exclude rules will be bypassed if a path that matches the rule is passed in explicitly in the command line"). Even if there isn't motivation to change current behavior, I would urge you to reconsider and re-open this ticket to at least address the documentation part, so I can point users to why the linter is not working as they expect (as you can see in the Github link in the subject). In an ideal scenario, some other flag that would allow strict exclude rules (that would be obeyed even if a path is passed in) would be implemented so that editor tools like |
In GitLab by @sigmavirus24 on Jan 24, 2015, 11:15
As far as I know
I'm always more than happy to accept updates to the documentation. This issue isn't about documentation though so it doesn't need to be reopened to address that.
You can point users to a closed issue just as easily as an open one. They don't disappear because they're closed.
The exclude rules are strict. The feature you want is exclude rules that take precedence over explicit user input. That's a counter-intuitive user experience in my opinion. Looking at Khuno's README (there doesn't seem to be any other documentation), you already provide a way to configure (via khuno) error codes to ignore and maximum line-length. If you were solely relying on Flake8 for that functionality (by forcing the user to place all of this in a config file) then I'd understand your concern, but it would seem you could just as easily have the user specify files to exclude and apply it yourself. |
In GitLab by @sigmavirus24 on Jan 24, 2015, 11:24 Also, for what it's worth, this functionality is provided by |
In GitLab by @arufuredosan on Jan 24, 2015, 17:20 By 'pointing users to why the linter is not working' I meant at least a portion in the documentation where it states that this is expected behavior, not a closed/open issue. You can't say something is strict (like the exclude rule) and then have an override. If it is strict, then it should be strict, otherwise it isn't. By definition, strict means obeying a rule exactly as it is. This is not doing that, therefore it isn't strict. The only way Any changes in The only workaround for If you believe some feature of |
In GitLab by @sigmavirus24 on Jan 24, 2015, 18:57
Right. I already said the project would accept a contribution that fixed its documentation.
It's as strict as every other linter. pep8 has the same behaviour (but as I've already mentioned, that's because pep8's logic powers flake8). pylint behaves the same way. If you create a
I never told you to update the
It's counter-intuitive because no other tool provides such an option. In fact, I'll go so far as to say it's an undesirable feature for everyone except This discussion is becoming cyclic so if you want to open a separate issue to document the behaviour, or even send the patch yourself, that's great, but I won't be responding. |
In GitLab by @arufuredosan on Jan 23, 2015, 13:10
On a setup.cfg file that has:
And a project that has the following layout:
If on the
project
directory and I run:Then the configuration will correctly kick in and
tests
will not be picked up.However, if we run:
Then that file gets linted.
Although it is non-obvious why someone ignoring
tests
would pass the file that is actually in the ignoreddirectory, it is how the
khuno.vim
plugin works. When on a given file (liketest_foo.py
) the pluginwill call
flake8
with the full path to report back the linting to the editor.Reference issue on
khuno
tracker: alfredodeza/khuno.vim#20The text was updated successfully, but these errors were encountered: