-
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
Speed up unpack_file_url #2535
Speed up unpack_file_url #2535
Conversation
E.g.: `pip install /path/to/dir` by building an sdist and then unpacking it instead of doing `shutil.copytree`. `shutil.copytree` may copy files that aren't included in the sdist, which means that: 1. If those files are large, a `pip install` could take much longer than it should. 2. Folks that are using `python setup.py install` to test their package are not fully testing it, because it may copy over files that wouldn't be there if they built and sdist and installed that. So this method building an sdist is both more accurate and faster. Fixes pypa#2195
👍 |
This one should probably require a few thumbs up before merging because my first attempt at this messed pbr and had to be reverted. So I'd love for OpenStack folks to give this a try and weigh in. |
This could replace #2533 |
@msabramo thanks! I'll run it through some pbr paces this weekend. |
Thanks, @emonty! I hope this change works better for pbr than my earlier one. It would be really nice to make |
Talked to @emonty on IRC and it appears like this works for pbr now. |
For posterity, atm, it looks like it was supposed to be
at Line 696 That said, when a function called |
This is a follow-up to pypagh-2535, which added the code to copy via (sdist + unpack) instead of shutil.copytree, but forgot to actually call that function. Fixes pypagh-2195 (slow pip install of a dir).
This works around a problem with the new sdist-based "pip install .": * when creating the sdist, we don't run a literal "setup.py sdist" * instead, sys.argv[0] is a complicated shim that injects setuptools even into distutils-based projects * as a result, distutils.command.sdist.add_defaults() doesn't realize that "setup.py" is the name of its setup script (it gets confused because sys.argv[0] is not a real file). * so add_defaults() doesn't include setup.py in the generated tarball. (projects could add "include setup.py" to their MANIFEST.in, but this is not common practice because usually it's automatic) * so the unpacked sdist (from which pip will make a wheel) lacks the critical setup.py This copies the setup.py from source tree to unpacked target tree. The patch also removes a performance comment that was obsoleted by switching to _copy_dist_from_dir(). refs pypa#2195, pypa#2535, pypa#3176
In case it helps: I compared |
E.g.:
pip install /path/to/dir
by building an sdist and then unpacking it instead of doing
shutil.copytree
.shutil.copytree
may copy files that aren't included in the sdist, which means that:pip install
could take much longer than it should.python setup.py install
to test their package are not fully testing it, because it may copy over files that wouldn't be there if they built and sdist and installed that.So this method building an sdist is both more accurate and faster.
Fixes #2195
Cc: @tomprince, @pfmoore, @dstufft, @fungi, @rbtcollins