-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Support Implicit Namespace Packages (PEP 420) #8153
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
Support Implicit Namespace Packages (PEP 420) #8153
Conversation
@Pierre-Sassoulas so it is done and it would be great to get the feedback so I can address it promptly :) |
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #8153 +/- ##
=======================================
Coverage 95.45% 95.46%
=======================================
Files 177 177
Lines 18635 18663 +28
=======================================
+ Hits 17788 17816 +28
Misses 847 847
|
49ca119
to
ae88477
Compare
This comment has been minimized.
This comment has been minimized.
e37d01d
to
6844c72
Compare
This comment has been minimized.
This comment has been minimized.
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.
I'm wondering if we could use the packaging information to discover the source root.
It's possible that making the user give the source root is the way to fix this once and for all. I did not review everything yet. I hope some other maintainer will have an opinion about this.
Changes to the namespace and file discovery are very frightening because there's not a lot of way to test it properly on the scale it needs to be tested to be sure it's not going to explode everywhere when we release it. So I'm very conservative when modifying this kind of code and I think we need extensive tests, maybe more (small) primers with implicit namespace package and various use cases.
@Pierre-Sassoulas thanks for your feedback and please find my comments below:
A good point, absolutely. Yet that should serve as one a source of source roots information if the pylint configuration misses one and is an improvement to the current implementation. Also, such auto-magic would be a breaking change since projects would need an upgrade, as minor upgrade would bring behavior change. Probably a change for 3.0 no less.
The current behavior remains unchanged so there shouldn't be a disaster once released and the test suite was expanded as well the new optional behavior. |
Thank you @alexey-pelykh for this work and especially for also thinking about I agree with Pierre that adding some projects that use implicit namespace packages would be a good idea. Besides that I was only wondering why it is necessary to create several new functions and deprecate the existing ones, when the now deprecated functions afterwards just delegate to the new functions. |
@DudeNr33 thanks for your feedback and please find my comments below:
Now I'm not sure I followed the idea correctly: adding projects as a test fixtures? adding where and how?
Both That said, the most robust solution would be to warn users that used API causes implicit guesswork via deprecation and provide an explicit way to force pylint do the guesswork via new method signatures. As a nice bonus, some naming adjustments could be be made. And in 3.0 release those deprecated methods would be removed. |
Thank you for the explanation of the deprecation warnings. I agree that this is then the cleaner approach!
Primer tests run
Unfortunately I have no further experience in dealing with the primer test suite, so the other maintainers can help you more with that. |
Thanks for explanation on primer tests, makes sense. Yet no open-source project that use PEP420 with 2+ depth comes to my mind really... Yet thus far nothing have changed for projects currently listed for the primer tests, right? |
poetry-core uses implicit namespace packages, but only one level deep. Nevertheless it could be a good candidate. Yes, for the existing primer projects all seems to be fine. |
981ece2
to
3403b8a
Compare
It is an ideal one as is appears, exactly what I was looking for. So I'll add it :) |
3403b8a
to
3b367f5
Compare
@Pierre-Sassoulas any insights what was this about? https://github.com/PyCQA/pylint/blob/main/pylint/testutils/_primer/primer_run_command.py#L78 Also, it feels like #8193 needs to go into main before this one to properly capture unchanged poetry-core priming? |
duplicate code is really slow, intrinsically solving a hard problem that scale pretty badly on big code base and the code almost never change so we removed it. For cyclic import I don't remember but maybe it's also slowness, maybe also that the result are not the same each run (?) |
eb80074
to
366c597
Compare
@Pierre-Sassoulas please rerun https://github.com/PyCQA/pylint/actions/runs/4102946645/jobs/7076537678 otherwise nothing will happen |
Trying to fix this in #8200 |
366c597
to
34bbef6
Compare
This comment has been minimized.
This comment has been minimized.
34bbef6
to
be0f56d
Compare
This comment has been minimized.
This comment has been minimized.
be0f56d
to
b8c5c56
Compare
This comment has been minimized.
This comment has been minimized.
Well, I guess all is in check now? |
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.
I only have a few wording suggestions, but they are no blocker imo.
However I think at least one other maintainer should additionally approve before merging.
Co-authored-by: Andreas Finkler <[email protected]>
Co-authored-by: Andreas Finkler <[email protected]>
No objections on proposed changes :) |
π€ According to the primer, this change has no effect on the checked open source code. π€π This comment was generated for commit 9428ba4 |
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.
Thank you for all the work, clearly a lot of care went into this. I don't see anything outrageous and there are tests that I think are reasonable. Let's wait a little for more reviews. Then we could release a 2.17 beta version to make sure there's no obvious issues before really releasing in the wild :)
# TODO: Remove deprecated function | ||
warnings.warn( | ||
"_patch_sys_path has been deprecated because it relies on auto-magic package path " | ||
"discovery which is implemented by get_python_path that is deprecated. " |
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.
We could announce a removal in 3.0, maybe 4.0 seeing that 3.0 is nearing.
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.
Looks good to me. π
Fixes #7959 by introducing the concept of source roots.
Type of Changes
Description
Closes #8154