-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Lint all files in a directory by expanding arguments #5682
Lint all files in a directory by expanding arguments #5682
Conversation
for more information, see https://pre-commit.ci
Marking as draft, since still missing polishing, tests and documentation. I would like to ask just for review of approach. |
Pull Request Test Coverage Report for Build 1799934875
π - Coveralls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think this is pretty clever. In fact this is what was done currently (in bash or pre-commit by each users) when launching pylint with a long list of files, so imo this is pretty safe too. We're probably missing some optimization of doing the sys path manipulation less internally but the alternative is a very complex change and waiting even longer for what has been the most wanted feature of the project for years. Goob job !
I think this is also pretty clever! I wonder if we could make it so that |
|
Agreed! But I was wondering if for |
The intent is pretty clear when doing that imo, so I'd say it's safe to put in 2.x. In fact my first instinct was to also make recursive the default in 2.x. But there's probably projects somewhere that use this "non feature" to exclude files from the linting, |
Thank you for your feedback. Let me finish the PR. I will close the previous one. |
462b0e3
to
20ad408
Compare
6c3e3c8
to
2aceafb
Compare
Test added, code cleaned up, added type annotations and docstrings. I have 2 questions:
|
If this was a new project, I would add a |
Would using
Yes, I would appreciate some documentation about it. If we make this default we can just update the documentation to reflect this! |
β¦ into discover_modules2
Co-authored-by: DaniΓ«l van Noord <13665637+DanielNoord@users.noreply.github.com>
Tests are failing for TestRunTC.test_regression_recursive_current_dir but it is working on my local computer. EDIT: it seems that the TC fails only when it is executed by command |
@matusvalo Does this pass for you locally? |
@@ -100,6 +100,24 @@ def _configure_lc_ctype(lc_ctype: str) -> Iterator: | |||
os.environ[lc_ctype_env] = original_lctype | |||
|
|||
|
|||
@contextlib.contextmanager |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could probably even go in tests/conftest.py
to be used everywhere ? I don't know how frequent it is. But we might want to do that in another MR, this one need to be merged π
Yes and no. the tests are failing only when executed by The reason is because pytest in case of executing tests via command But as said before only in case of running Note: I am not sure whether the behaviour causing failing tests is expected or it is bug in Astroid. But I think it is not connected to this PR. |
I have merged main to fix conflict. @DanielNoord is there anything pending in this PR? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry @matusvalo, was swarmed at work and didn't really have the time to look into this.
One final question (and some spelling fixes). π
Co-authored-by: DaniΓ«l van Noord <13665637+DanielNoord@users.noreply.github.com>
All suggestions resolved. Only point is just Iterator vs. Generator question. Let me know about it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Daniel spotted these errors but was working just a bit quickly when suggesting the fix :-)
Co-authored-by: Jacob Walls <jacobtylerwalls@gmail.com>
Thank you @jacobtylerwalls ! |
This is a huge improvement to pylint, thank you @matusvalo ! |
Type of Changes
Description
This PR is alternative to #5676 trying to resolve
sys.path
adjustment issue mentioned in #352 (comment).The main rationale of this PR is to introduce recursive discovery of python modules/packages transparently to rest of pylint components. This is done by
expanding arguments containing directories with all modules and packages inside this directory. This approach should be safe with #352 (comment) since this change is totally transparent to
sys.path
adjustments in pylint. Hence for following subtree:Executing command
pylint --recursive test
is equal to executing commandpylint test/a.py test/b.py test/c
.Closes #352