-
-
Notifications
You must be signed in to change notification settings - Fork 31.5k
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
gh-92897: Ensure venv --copies
respects source build property of the creating interpreter (GH-92899)
#92899
Conversation
… of the creating interpreter.
Don't touch distutils - it's going to be deleted in this release anyway, and there are no maintenance releases where it is undeprecated. If we're using it within the stdlib, update the references elsewhere. If setuptools is impacted, they need the patch. I haven't looked any deeper than that - it's late. I'll try and take a look later this week |
The changes to distutils are only to keep it from raising exceptions. Since it is being removed, I saw no need to keep private functions around just for use within distutils which would prevent a more straight forward implementation. Hence the modifications to distutils. The changes to stdlib |
In practice, setuptools now injects its own distutils flavor, so I am not sure that it's worth it to modify it here. At least, you should get your change merged first in https://github.com/pypa/distutils/ |
|
To make it absolutely clear, the changes here to |
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.
LGTM, and appears to handle the case on Windows where a venv is created from a source build. I can only assume the behaviour is correct on other platforms?
As far as other platforms go, it is tested on Ubuntu (WSL). |
venv --copies
respects source build property of the creating interpretervenv --copies
respects source build property of the creating interpreter (GH-92899)
Sorry, @jkloth and @vsajip, I could not cleanly backport this to |
Sorry @jkloth and @vsajip, I had trouble checking out the |
…roperty of the creating interpreter (pythonGH-92899) (cherry picked from commit 0675975) Co-authored-by: Jeremy Kloth <jeremy.kloth@gmail.com>
GH-94567 is a backport of this pull request to the 3.11 branch. |
… of the creating interpreter (pythonGH-92899) (cherry picked from commit 0675975)
GH-94572 is a backport of this pull request to the 3.10 branch. |
There is a discrepancy between a symlink venv and a copied venv when determining whether the interpreter is considered to be from a source build. A symlink venv indicates
True
forsysconfig.is_python_build()
whereas a copied venv returnsFalse
.Since symlink venvs are the default for POSIX (where the majority of source builds would be used/tested), I have opted to use that behavior as correct. Windows users are far more likely to use the binary installer so odds of venvs being created from source builds are quite low. Likewise with
venv --copies
on POSIX.These changes will allow for building extensions out of venvs created from source builds without any pre-configuration steps (see this section from pyperformance documentation).
Adding @zooba for Windows and @vsajip for venv