Drop the pyvenv script #69341
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
assignee = 'https://github.com/brettcannon' closed_at = <Date 2015-10-27.00:11:39.712> created_at = <Date 2015-09-17.18:35:21.344> labels = ['type-bug', 'expert-installation'] title = 'Drop the pyvenv script' updated_at = <Date 2015-10-27.00:11:39.684> user = 'https://github.com/brettcannon'
activity = <Date 2015-10-27.00:11:39.684> actor = 'brett.cannon' assignee = 'brett.cannon' closed = True closed_date = <Date 2015-10-27.00:11:39.712> closer = 'brett.cannon' components = ['Installation'] creation = <Date 2015-09-17.18:35:21.344> creator = 'brett.cannon' dependencies =  files = ['40579', '40861'] hgrepos =  issue_num = 25154 keywords = ['patch'] message_count = 18.0 messages = ['250910', '250912', '250920', '250923', '251021', '251457', '251543', '251605', '253102', '253185', '253263', '253264', '253385', '253386', '253444', '253445', '253457', '253508'] nosy_count = 10.0 nosy_names = ['barry', 'brett.cannon', 'doko', 'pitrou', 'scoder', 'eric.smith', 'ezio.melotti', 'python-dev', 'rpointel', 'lac'] pr_nums =  priority = 'normal' resolution = 'fixed' stage = 'resolved' status = 'closed' superseder = None type = 'behavior' url = 'https://bugs.python.org/issue25154' versions = ['Python 3.5', 'Python 3.6']
The text was updated successfully, but these errors were encountered:
I propose that the pyvenv script be deprecated in Python 3.5 and removed in Python 3.8. The reason for this proposal is because it is non-obvious what version of Python a pyvenv command is tied to (heck, it isn't necessarily obvious that it's Python 3). There would be no loss in functionality since the exact same functionality is available through
As pointed out in issue bpo-25152, virtualenv provides a -p flag to specify what version of Python should be used to create a virtual environment: https://virtualenv.pypa.io/en/latest/reference.html#virtualenv-command. The pyvenv script and venv package provide no such mechanism since it is included in the stdlib, which makes sense since improvements will be tied to the stdlib of the Python interpreter being used while virtualenv is a standalone project/app.
Some may argue that worrying about this is unnecessary, but we are already ending up with OSs that come with multiple versions of Python pre-installed, let alone when people install their own versions of Python on top of the system installation. For instance, OS X Yosemite comes with Python 2.6 and 2.7, and then if you install the latest version of Python independently you end up with 3 installations. If they all happened to have a pyvenv script you wouldn't easily know which Python interpreter the pyvenv command was going to use for the virtual environment.
Since the pyvenv script is just a script, the deprecation will be in the form of a message printed to sys.stderr in the Tools/scripts/pyvenv file mentioning that the deprecation and that people should switch to
Due to debian policy decision
neither pyenv nor python -m venv
may work for you.
While things are getting changed, it would be good if people running into
Error: Command '['<directory>/bin/python3.4', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1
such as 'Your python may not be configured with ensure-pip'
There's a typo here in 'executable':
And this could now be:
And since there is no .format() call, you can't accidentally pass it file=.