Fix: "pip install ." fails on Python 3.3 (with symlinks in local directory) #1311
Conversation
Without this, "pip install" crashes when encountering symlinks that point to external paths. The culprit is "shutil.copytree()", which throws an error in such cases if the "symlinks" parameter is not set to "True". This fixes pypa#1006.
|
duplicate #813 |
|
Wow, three pull requests already and still not merged. |
|
ok, marking for 1.5. looking now. |
|
ok, giving this a tentative merge +1, but want someone else to confirm it . my admitted paranoia with this, was that it can somehow add a security risk. this change specifically deals with copying the change here is from:
|
|
also, I confirmed the test fails without the |
| @@ -359,7 +359,7 @@ def unpack_file_url(link, location): | |||
| # delete the location since shutil will create it again :( | |||
| if os.path.isdir(location): | |||
| rmtree(location) | |||
| shutil.copytree(source, location) | |||
| shutil.copytree(source, location, symlinks=True) | |||
There was a problem hiding this comment.
Presumably this works on Windows? Is it ignored, or does it attempt to copy symlinks? If the latter, then it may fail because the pip process is not elevated (creating symlinks needs an elevated process on Windows).
There was a problem hiding this comment.
not sure. wanna check it? : )
There was a problem hiding this comment.
It'll be a few days before I can, at best. I'm assuming that the test will fail on Windows because setting up a test directory with symlinks needs an elevated process. Running some tests to make sure "normal use" still works is more what matters to me, but I don't know what we'd need to do to make sure this code is exercised in a non-symlink case.
It's probably a non-issue, though, I did a quick test and copytree(..., symlinks=True) works unchanged when the source directory doesn't have symlinks, so there should be no issue.
There was a problem hiding this comment.
I don't think this test will fail on windows, but rather, it's not valuable on windows. these are "linux" symlinks (in the "symlinks" test package that was added), not NTFS symlinks, so they're just files to windows. but I don't know windows that well, so I may be wrong.
2 things need to be confirmed on windows. If a project contains true NTFS symlinks:
- how does our current code behave in py3? does it fail?
- how does it behave after the change? require elevated privileges?
I have to pass on looking into this. Someone who's more comfortable with windows, or more motivated to get this change, needs to confirm it.
There was a problem hiding this comment.
I'm not going to do this, it's not that important to me, and working with symlinks on Windows is a pain. But if someone does want to get this in, I'm not going to block it on the basis of a theoretical risk.
There was a problem hiding this comment.
@qwcode
(1) look at this #813 (comment) obviously need testing
(2) it require elevated privileges indeed (source: @docs.python: os.symlink and @wikipedia: NTFS_symbolic_link)
|
This looks fine to me, I'll merge it. |
Fix: "pip install ." fails on Python 3.3 (with symlinks in local directory)
|
Thanks. |
lock
bot
added
the
auto-locked
This pull request (hopefully) fixes GitHub issue #1006, and includes a separate test case for the issue.