-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Build local directories in place #7882
Conversation
61602fe
to
6b6dee2
Compare
This is getting in good shape. As expected some tests had to be changed to cope with the The only thing that stands out is this @pypa/pip-committers what do you think? Should I continue down this path? |
The Travis failures are all the same, the worker has problems reaching PyPI for setup (it didn’t even reach the test phase). |
@sbidoul Sounds like a good idea! Still need to look at this PR, and hopefully by the time this gets updated, I'd have cleaned up my notifications situation significantly. :) |
Note: maybe we should disable the copy while keeping the code around to facilitate an emergency revert in case this change raises problem for valid uses cases we'd have not anticipated. And then remove the dead code after 3 months. |
1969caa
to
1cbbf58
Compare
|
1cbbf58
to
1a2a433
Compare
@sbidoul Do you want this to be on the pip 20.1 release? I personally think it would reasonable to try to be on this train, since bundling this in the same release as the new resolver... might not be the best thing to do. OTOH, it might feel hurried to some but, hey, who knows. :) Plus, this isn't a big "code change" but is a whole bunch of communication + community management discussion. We will have a beta period for 20.1, and it'd make a lot of sense to try to get feedback on this change as part of that IMO. |
1a2a433
to
516e6c0
Compare
@pradyunsg ok, to get this out in 20.1. TIL there will be a beta period, so yes it's a good candidate to test the beta feedback process. |
516e6c0
to
9fd3384
Compare
It got announced today. :P |
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.
Implementation -- LGTM.
Documentation -- would be important to have for this IMO; NEWS fragment feels like it's compensating for the lack of docs. :/
Building of local directories is now done in place. Previously pip did copy the | ||
local directory tree to a temporary location before building. That approach had | ||
a number of drawbacks, among which performance issues, as well as various | ||
issues arising when the python project directory depends on its parent | ||
directory (such as the presence of a VCS directory). The user visible effect of | ||
this change is that secondary build artifacts, if any, may therefore be created | ||
in the local directory, whereas before they were created in a temporary copy of | ||
the directory and then deleted. This notably includes the ``build`` and | ||
``.egg-info`` directories in the case of the setuptools build backend. |
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 feels a bit excessive. I think we should only summarize the change here, add a section to the documentation and link to that from here.
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.
@pradyunsg would you have a suggestion about a suitable place for this in the documentation?
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.
https://pip.pypa.io/en/latest/reference/pip_install/#local-project-installs needs updating, so that would likely be the best place.
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.
@pradyunsg thanks for the documentation pointer, I updated that section. Regarding the changelog I thought the breaking change warranted a bit more verbosity than usual.
9fd3384
to
c001102
Compare
Since we now build in place, pip install calls setup.py in place which in turn creates fake_pkg.egg-info. Since in this test the package we are installing is in script.temp_path, we must tell script to expect temporary files to be created.
This particular test checks which files are created. Since we now build in place, expect the .egg-info directory to be created.
c001102
to
877e1cc
Compare
Co-Authored-By: Noah <noah.bar.ilan@gmail.com>
LGTM! I think I'll try to do another pass on the documentation prior to the release, but no promises. Let's open the flood gates, AKA merge this PR! \o/ |
Hurrah! Thanks for actually figuring out a small-patch-that's-actually-reasonable for doing this! ^.^ Thanks @NoahGorny for taking a look and for the reviews + inputs @xavfernandez @uranusjr! ^>^ |
Thanks @pradyunsg. I went ahead and closed #7555 and linked issues. |
Oh... I was waiting until after the beta release, to use those issues to get users to test the beta and report feedback on this change, instead of closing them now, which sorta indicates that "there's nothing more to do here". I guess we can still post the "hey test this beta" messages posted there, but it might not have the same effect anymore. This makes things a bit more... tricky... in terms of communicating around this change. :/ |
Oh, sorry. I was under the impression that we were always closing issues as soon as the fixing PR was merged. I did not know you wanted to apply another process here. Wrt the beta process, I personally have little doubt the above issues are resolved with this PR, so the beta process is probably not so much about verifying that. We probably need to focus on surfacing possible new issues that this change may create to users and use cases we don't know yet. And communicate clearly about potential impacts. |
Yea, it's not like you did anything inappropriate or anything along those lines. I'm still figuring out how exactly to phrase the communication around this, which is basically why I hadn't actually commented that I'm thinking about using this approach. We learn more as we do more stuff, I guess. :P |
Starting with pip 20.1b1+, the *-info subdir appears as a build artifact under the "local" directory (here, /project). See - pypa/pip#7555 - pypa/pip#7882 - pypa/pip@ace0c16
This is a rough experiment with in-place builds, to see the effect on the code base and tests, and advance the discussion in #7555.