Skip to content
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

The -p N.M shortcut doesn't work for Python 3.5 on Windows #864

Closed
pfmoore opened this issue Feb 3, 2016 · 4 comments
Closed

The -p N.M shortcut doesn't work for Python 3.5 on Windows #864

pfmoore opened this issue Feb 3, 2016 · 4 comments

Comments

@pfmoore
Copy link
Member

pfmoore commented Feb 3, 2016

The --python command line can take an abbreviated interpreter name. On Unix this is one of the versioned alias names (python2.7, python3, ...) and is looked up on PATH.

On Windows the versioned names don't exist so the registry is searched for the Python version specified. So, -p 2.7 finds the location of Python 2.7 in the registry and uses that.

However, the registry layout is not well documented, and is complex (user installs, 32-bit vs 64-bit). It also seems to have changed in Python 3.5, and -p 3.5 does not work. Rather than attempt to fix this, though, I propose that the feature be marked as deprecated, and left as it stands. It's not clear that it was ever widely used.

People wanting to use an abbreviated interpreter name would be better to run py -N.M -m virtualenv (assuming virtualenv is installed under Python N.M) or py -N.M C:\path\to\virtualenv to run a standalone copy of virtualenv. This uses the (fully supported) Python launcher to select the required Python version.

@Ivoz
Copy link

Ivoz commented Feb 3, 2016

+1, never even knew that was a thing.

If we want to do it nicely, probably want a patch logging it's deprecated when that is used for next release, and a deprecation note in the dev rel notes.

@pfmoore
Copy link
Member Author

pfmoore commented Feb 3, 2016

IIRC, it's a thing because I added it because I was too lazy to type in the full interpreter. Then I never actually used it. Go figure.

Yeah, I'll see if I can work up a proper deprecation note. For now, I mainly raised the issue so we had somewhere that said "it's broken and not going to get fixed" to justify me skipping the test I just added for the feature :-)

@jurko-gospodnetic
Copy link

@asottile - this is actually important for your pre-commit project as it wants to be able to easily request a specific Python version to run a pre-commit hook, but does not want to duplicate the effort of detecting the installed Python executable location.

@stale
Copy link

stale bot commented Jan 14, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Just add a comment if you want to keep it open. Thank you for your contributions.

@stale stale bot added the wontfix label Jan 14, 2019
@stale stale bot closed this as completed Jan 21, 2019
@pypa pypa locked and limited conversation to collaborators Jan 14, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants