-
-
Notifications
You must be signed in to change notification settings - Fork 30.7k
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
bpo-45413: Define "posix_venv", "nt_venv" and "venv" sysconfig installation schemes #31034
Conversation
The scheme is used for bootstrapping new virtual environments. It is a copy of the "posix_prefix" or "nt" install scheme depending on the platform. The venv module now uses that scheme to create new virtual environments instead of hardcoding the paths depending only on the platform. Downstream Python distributors customizing the "posix_prefix" or "nt" install scheme in a way that is not compatible with the install scheme used in virtual environments are encouraged to supply a modified working "venv" scheme.
The tests have that one instead. This reverts commit 4686893.
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.
Thank you for looking into this! Though, I do have some concerns about if the approach taken was the correct one.
It is a copy of the "posix_prefix" or "nt" install scheme depending on the platform.
I think this is a bit messy, and not very nice for long term maintainability. There is also the existing issue of distributors patching the posix_prefix
scheme, which would mess this up, and while that is not officially supported, it would be best to try to preemptively mitigate any issues there, as long as it is a reasonable option for CPython.
When I opened the issue, I envisioned adding a completely new scheme, and making the interpreter select those paths when we are in a virtual environment. We already have code to detect this (hint: pyvenv.cfg
), so it should just be a matter of hard-coding the paths there.
This would also make the scheme be the same across operating systems, which is fairly neat IMO. prefix
would be the virtual environment path, and everything builds from there.
That said, I would like both @jaraco and @zooba to take a look, if they are available. If not, I think it would be best to delay merging this for a bit, but I am not a core dev, so my opinion doesn't matter much there, if anyone is confident enough with it, go ahead and merge I guess 😅
We can certainly make get_prefered_scheme return "venv" in venvs. I don't know if it needs to be done as part of this change. |
Oh yeah, that is something I overlook in this preliminary review. I think we should definitely do that. |
OK, this is now done. But I am not sure if this is what I wanted :D |
Thank you! |
Who else do should comment here before you can send the PR? |
This is confusing: why run to merge something before it’s complete? |
This PR is complete now. There is discussion about how it can be made better, and that discussion is not really moving forward. Everyone is waiting for something while a fix is ready. |
Ah, I thought |
Right, my wording was ambiguous. |
I think it is safe to say that the current state of the PR isn't clear to be the best approach. I don't understand the eagerness to merge this right now, I think that can do more harm than good. The issue this PR solves already exists in the current released version, 3.10. We will not be able to fix it in that version, that ship has sailed. To work around this, we have already designed an approach to deal with this issue, which was adopted by the impacted parties (see pypa/virtualenv#2208). This PR, which would land in 3.11, is incompatible with the adopted workaround, requiring more changes to the downstreams, and introducing more complexity in version compatibility code. If we merge it as-is and it gets released, we put more weight on the downstreams, and even more if it turns out that we need to change the approach later. So, my proposal would be to drop Most of my concerns with the current implementation, other than it being incompatible with the 3.10 workaround, are due to long term maintainability and distributors messing things up with patching, and can be solved just by changing the internal implementation, without breaking compatibility. We can handle them later. |
Not really. It is an issue in Python 3.10+ software, period. It was just introduced by changes to support the distutils deprecation, but this affect all Python 3.10 software that is on the business of manually creating virtual environments. |
So, the "venv" scheme would do what the function currently does, and the platform specific schemes would stay? I can do that as well. |
Yes, exactly. |
@zooba, what do you think about that? |
I've committed Drop get_venv_scheme() in favor of venv scheme. It can be reverted if @zooba does not like it. I would squash those together, but I've been told not to push force. |
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.
Looks good to me. (Apologies for unresponsiveness - GitHub notifications are a bad way to reach me, unfortunately. bpo messages are far more reliable due to no noise.)
Co-authored-by: Steve Dower <[email protected]>
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.
Thanks, this is significantly better IMO.
We can improve the implementation later if needed.
@encukou I suspect direct emails are going to become important for me once all notifications move to GitHub. I can only see things getting even worse than they are now 😞 |
As a result of python/cpython#31034, venv now calls sysconfig.get_paths. This messes up the mock call count. The change to using Signature.bind isn't strictly necessary, but fixes the initial symptom (since venv calls sysconfig.get_paths without kwargs). This also means we can use sysconfig.get_paths however we want.
* Fix mock in test_executable_missing_post_creation for Python 3.11 As a result of python/cpython#31034, venv now calls sysconfig.get_paths. This messes up the mock call count. The change to using Signature.bind isn't strictly necessary, but fixes the initial symptom (since venv calls sysconfig.get_paths without kwargs). This also means we can use sysconfig.get_paths however we want. * add comment, unskip on pypy3 * mock venv.EnvBuilder.create * remove unused imports Authored-by: hauntsaninja <>
Define posix_venv and nt_venv sysconfig installation schemes
to be used for bootstrapping new virtual environments.
Add venv sysconfig installation scheme to get the appropriate one of the above.
The schemes are identical to the pre-existing
posix_prefix and nt install schemes.
The venv module now uses the venv scheme to create new virtual environments
instead of hardcoding the paths depending only on the platform. Downstream
Python distributors customizing the posix_prefix or nt install
scheme in a way that is not compatible with the install scheme used in
virtual environments are encouraged not to customize the venv schemes.
When Python itself runs in a virtual environment,
sysconfig.get_default_scheme and
sysconfig.get_preferred_scheme with
key="prefix"
returnsvenv.
https://bugs.python.org/issue45413