Repository navigation
PEP 453: add the ensurepip module #63605
Description
| BPO | 19406 |
|---|---|
| Nosy | @loewis, @ncoghlan, @larryhastings, @ned-deily, @dstufft |
| Files |
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
GitHub fields:
assignee = 'https://github.com/ncoghlan'
closed_at = <Date 2013-11-11.12:15:25.961>
created_at = <Date 2013-10-26.12:42:33.552>
labels = ['type-feature', 'library', 'release-blocker']
title = 'PEP 453: add the ensurepip module'
updated_at = <Date 2013-11-11.12:23:23.191>
user = 'https://github.com/ncoghlan'bugs.python.org fields:
activity = <Date 2013-11-11.12:23:23.191>
actor = 'ncoghlan'
assignee = 'ncoghlan'
closed = True
closed_date = <Date 2013-11-11.12:15:25.961>
closer = 'python-dev'
components = ['Library (Lib)']
creation = <Date 2013-10-26.12:42:33.552>
creator = 'ncoghlan'
dependencies = []
files = ['32374', '32386', '32434', '32435', '32446', '32458', '32566']
hgrepos = []
issue_num = 19406
keywords = ['patch']
message_count = 32.0
messages = ['201342', '201349', '201350', '201352', '201357', '201435', '201462', '201806', '201807', '201808', '201815', '201872', '201873', '201951', '201952', '201953', '201954', '201955', '201956', '201957', '201958', '201959', '202137', '202138', '202140', '202530', '202559', '202608', '202609', '202613', '202619', '202620']
nosy_count = 7.0
nosy_names = ['loewis', 'ncoghlan', 'larry', 'ned.deily', 'tshepang', 'python-dev', 'dstufft']
pr_nums = []
priority = 'release blocker'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue19406'
versions = ['Python 3.4']
Activity
ncoghlan commentedon Oct 26, 2013
Adding the initial ensurepip implementation and module docs
(the "Installing Python Modules" updates will be handled in a separate issue)
ncoghlan commentedon Oct 26, 2013
bpo-19347 tracks overall PEP-453 implementation progress
dstufft commentedon Oct 26, 2013
Attached is an initial rough draft of the ensurepip module. There are some issues still, but they largely need resolved in pip.
If you prefer to view it on github my branch for working on it is available at https://github.com/dstufft/cpython/compare/ensurepip
dstufft commentedon Oct 26, 2013
Added a second draft that handles the case when the stdlib isn't directly browseable (e.g. it's zipped up or something).
dstufft commentedon Oct 26, 2013
Added a third draft, this one adds the script to check if pip needs updated. I've removed the first two drafts to make it simpler.
ncoghlan commentedon Oct 27, 2013
Draft docs patch attached. This splits out a new "Software Packaging and Distribution" section in the main docs index, with distutils, ensurepip and venv as the specific entries.
There's a couple of questions I need answered regarding the behaviour of pip in order to document --user properly:
dstufft commentedon Oct 27, 2013
You cannot use --user in a virtual environment (well a venv, no idea about a pyvenv - but it should get a similar error message IMO if it doesn't).
If you use --root and --user together it will install to the --root location, using the user layout, so instead of installing to /home/dstufft/.local/lib/python3.4/site-packages/ it will install to /value/of/root/home/dstufft/.local/lib/python3.4/site-packages/
ncoghlan commentedon Oct 31, 2013
Added most of the nosy list from the tracking bpo-19347.
Updated draft docs. I believe this version of the module docs should be complete (since the installation guide updates are covered by bpo-19407).
While Donald's attached patch is incomplete, the version on GitHub looks basically ready to go (aside from --root not working when running pip from a wheel file): https://github.com/dstufft/cpython/compare/ensurepip
Shall we proceed with the commit based on the currently available pip, so Martin and Ned can get started on the installer updates?
dstufft commentedon Oct 31, 2013
For what it's worth I can get --root ready to go shortly, I have a patch against pip for it (pypa/pip#1272) I just need to write some tests to ensure it keeps working. Let me go off and do that right now.
dstufft commentedon Oct 31, 2013
I also need to update the bundled Wheel to one that was created with Python 3.4 instead of 2.7 (which matters until the fix for pypa/pip#1067 which is pypa/pip#1251 lands). That fixes the issue where the wheel will have pip2, and pip2.7 baked into it.
dstufft commentedon Oct 31, 2013
Ok, merged in the --root fix to pip and created a Wheel using Python 3.4 (which I installed the Wheel distribution using an ensurepip installed pip ;) ).
Updated on github and a patch added, all outstanding issues that affect this patch exist on the pip side of things. Primarily pypa/pip#1067 which, since I created the new pip wheel using 3.4, only affects this patch in that setuptools is still version specific. This'll be fixed soon in pip.
ncoghlan commentedon Nov 1, 2013
Donald, could you upload an updated patch here that includes both your changes and my docs updates?
We'll give people a day to look it over, and then go ahead and commit it and create the tracker issues to update pyvenv/venv and the Mac OS X and Windows installers.
10 remaining items
ncoghlan commentedon Nov 4, 2013
I created pypa/pip#1294 for the script versioning issue on the pip side, as I'd prefer not to be doing the temporary directory dance if we don't need to.
How do we want to handle this for beta 1? Is it OK to do an initial commit that has the installation of non-versioned scripts as a known defect so we can make progress on the rest of the changes in the meantime?
Alternatively, we could perhaps tweak the embedded wheels as an interim fix until the problem is addressed upstream.
dstufft commentedon Nov 4, 2013
Tweaking the Wheels won't work. The scripts are generated at install time.
We need to fix it in pip, I was waiting on answers to http://bugs.python.org/issue19406#msg201954 before coming up with a solution and making a PR request as that will influence the proposal/PR I make to pip. Basically we need to figure out what is considered reasonable during the initial ensurepip, and subsequent pip install --upgrade pip.
ncoghlan commentedon Nov 4, 2013
I'm OK with an unqualified "pip install --upgrade pip" retaining pip's current behaviour of always writing the unqualified script versions.
However, running "pip3 install --upgrade pip" would ideally leave the "pip" and "easy_install" scripts alone.
For "make altinstall" compatibility, we definitely need a "--altinstall" flag that only installs the fully qualified versions of pip and easy_install.
Finally, there needs to be some way to explicitly request the "pip3" style behaviour when running via -m so we can use it from ensurepip.
ncoghlan commentedon Nov 10, 2013
Donald, I know you've been busy with PyPI v2.0 the last few days, but I see the pull request to resolve pypa/pip#1294 has been merged.
If we can get an updated patch that sets ENSUREPIP_OPTIONS appropriately in the process environment, it should be possible to commit this one and let Ned and Martin get started on the installers.
dstufft commentedon Nov 10, 2013
ncoghlan commentedon Nov 11, 2013
Assigning to myself for final review and commit :)
ncoghlan commentedon Nov 11, 2013
I'm also going to start creating the implementation issues for the installer and pyvenv updates.
ncoghlan commentedon Nov 11, 2013
The inconsistency between altinstall and default_install bothered me, so I plan to change the spelling of the latter option to "default_pip" (since it directly controls whether or not the "pip" script gets installed).
python-dev commentedon Nov 11, 2013
New changeset 6a6b1ee306e3 by Nick Coghlan in branch 'default':
Close bpo-19406: Initial implementation of ensurepip
http://hg.python.org/cpython/rev/6a6b1ee306e3
ncoghlan commentedon Nov 11, 2013
Aside from the default-install -> default-pip name change, the other fixes/changes between Donald's last patch and the committed version: