-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Implement PEP 660 allowing both "strict" and "lax/loose" approaches #3265
Implement PEP 660 allowing both "strict" and "lax/loose" approaches #3265
Conversation
FAQ about the implementation:Why is the implementation much more complex than the previous PoCsThis implementation tries to handle the implicit requirement that came up in the previous discussions: allow the user to chose which trade-off makes more sense for the use case in hands. Naturally, supporting multiple strategies instead of only one increases code size/complexity Why
|
Downsides/short-comings of the proposed implementation
|
891711f
to
e2135d5
Compare
Updates:
|
Hi Anderson. Thanks for all the hard work on this effort. I'm really excited to see the progress. Thanks also for providing an overview of the approach and its downsides. I haven't reviewed the implementation specifically, but based on the description you've provided, it sounds like you've found a fairly robust solution. If you're even moderately happy with it, I'm happy to move forward with it. |
Thank you very much Jason. I will wait a few days to see if Paul has any objection, otherwise I will go ahead and follow a very similar process that I did for PEP 621 and ask for feedback from the community (maybe using a beta version?). |
Ok, my plans moving forward:
Footnotes
|
50c1d09
to
d931716
Compare
Changes: - Deprecate the --egg-base parameter for dist_info and add --output-dir as replacement (Since the egg format is mostly deprecated, it is nice to move away from this nomenclature...)
This workaround can be reverted when issue 3261 is fixed.
- Add implementation of editable strategy based on a link tree - This is the `strict` implementation. - Only files are linked, not directories. - This approach makes it possible to use harlinks when softlinks are not available (e.g. Windows) - It also guarantees files that would not be part of the final wheel are not available in the editable install. - Add non-editable files to the produced wheel wheel (e.g. `headers`, `scripts`, `data`)
According to the PEP 420, namespace packages need to gracefully handle later additions to path. - Use a `PathEntryFinder` + an arbitrary placeholder entry on `sys.path` to force `PathFinder` to create a namespace spec. - Since `_NamespacePath` and `_NamespaceLoader` are private classes (or just documented for comparison purposes), there is no other way to implement this behaviour directly [^1]. [^1]: Reimplementing _NamespacePath + a custom logic to maintain namespace portions don't have a corresponding path entry also seems to have the same end result.
d931716
to
daaf3ab
Compare
Any idea when this will make it into a release? |
It will hopefully soon. This was the initial proof of concept to see if the other maintainers agree with the approach. I am refining the implementation now to make it more appropriate for a release. Then the plan is to open for the community to test and then an actual release. |
@theo-brown, please feel free to participate of the preliminary round of tests :) |
@@ -46,6 +46,8 @@ | |||
'prepare_metadata_for_build_wheel', | |||
'build_wheel', | |||
'build_sdist', | |||
'get_requires_for_build_editable', |
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.
@abravalheri You forgot to add 'prepare_metadata_for_build_editable'
to the __all__
list.
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 PR is an attempt to implement editable installs (PEP 660) in such a way that it allows for both “strict” and “loose/lax” editable installations. The overall approach, and the rationale behind which “editable mode” is picked by default is discussed in https://discuss.python.org/t/pep-660-and-setuptools/14855/2.
Summary of changes
bdist_wheel
and avoid re-implementingwheel
logicnamespace_packages
handling (based on the existingdevelop
command).pth
filessrc-layout
..pth
files.MetaPathFinder
and offers the following improvements over the existing implementation (develop
command):package_dir
mappingssys.path
(As always) this task ended up being tricker than I was expecting, so I also divided this PR in a series of smaller PRs that can be reviewed independently (but only if the reviews think that reviweing separated PRs can help). Let me know if there is anything different I could do to facilitate the review.
Note, however, that this division was an afterthought, so between “sub-PRs” there might be transient code/changes that are not part of the end result.
dist_info
to use--output-dir
instead of--egg-base
abravalheri/setuptools#9bdist_wheel
abravalheri/setuptools#3namespace_packages
ineditable_wheel
abravalheri/setuptools#4.pth
file abravalheri/setuptools#5MetaPathFinder
for top-level packages abravalheri/setuptools#7Side note
For the sake of not increasing even more the size of the change, I am currently not providing any news fragment or docs for the implementation. Depending on how the feedback/review go, I would provide that in a later stage.
Work towards #2816.
Pull Request Checklist
changelog.d/
.(See documentation for details)