This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ned.deily
Recipients dstufft, larry, loewis, ncoghlan, ned.deily, tshepang
Date 2013-11-01.23:52:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1383349954.67.0.462385670935.issue19406@psf.upfronthosting.co.za>
In-reply-to
Content
Here are my review comments (sorry, no Rietveld):

ensurepip/__init__.py
---------------------

Why have the separate _run_pip function?  It would be simpler and less confusing to just merge run_pip into bootstrap and eliminate the extra for loop.  Both depend on the _PROJECTS list anyway. --  Ah, I see that the reason for the separation is for mocking purposes in test_ensurepip.  How about constructing the list of paths to insert in bootstrap and passing that as the new second argument to _run_pip.  Then the knowledge about the wheel names is only in one place.


test_ensurepip.py
-----------------

s/bootsraping/bootsrapping/g


checkpip.py
-----------

It would be useful if checkpip.py returned an non-zero exit status in the case any projects are out-of-date.


Makefile.pre.in
---------------

Need to add ensurepip and ensurepip/_bundled to LIBSUBDIRS so that they are installed.


ensurepip/_bundeled
-------------------

The actual wheel files are not in the patch.  For other reviewers, Donald pointed me to their source here:
https://github.com/dstufft/cpython/blob/ensurepip/Lib/ensurepip/_bundled/


Using those wheels, which, as Donald notes, are preliminary (especially the setuptools one), I did some installs using a non-standard --prefix for python.  Here are the contents of the bin directory (what would be installed into /usr/local/bin by default) after "make altinstall".

$ ls -l bin
total 18760
-rwxr-xr-x  1 nad  pyd      110 Nov  1 15:08 2to3-3.4*
-rwxr-xr-x  1 nad  pyd      108 Nov  1 15:08 idle3.4*
-rwxr-xr-x  1 nad  pyd       93 Nov  1 15:08 pydoc3.4*
-rwxr-xr-x  2 nad  pyd  4791296 Nov  1 15:08 python3.4*
-rwxr-xr-x  2 nad  pyd  4791296 Nov  1 15:08 python3.4dm*
-rwxr-xr-x  1 nad  pyd     2041 Nov  1 15:08 python3.4dm-config*
-rwxr-xr-x  1 nad  pyd      245 Nov  1 15:08 pyvenv-3.4*

Now after python3.4 --ensurepip is run:

-rwxr-xr-x  1 nad  pyd        110 Nov  1 15:08 2to3-3.4*
-rw-r-----  1 nad  pyd        687 Nov  1 15:19 easy_install
-rw-r-----  1 nad  staff      355 Nov  1 15:19 easy_install-3.3.pya
-rw-r-----  1 nad  pyd        687 Nov  1 15:19 easy_install-3.4
-rw-r-----  1 nad  staff      347 Nov  1 15:19 easy_install.pya
-rwxr-xr-x  1 nad  pyd        108 Nov  1 15:08 idle3.4*
-rw-r-----  1 nad  pyd        659 Nov  1 15:19 pip
-rw-r-----  1 nad  pyd        659 Nov  1 15:19 pip3
-rw-r-----  1 nad  pyd        659 Nov  1 15:19 pip3.4
-rwxr-xr-x  1 nad  pyd         93 Nov  1 15:08 pydoc3.4*
-rwxr-xr-x  2 nad  pyd    4791296 Nov  1 15:08 python3.4*
-rwxr-xr-x  2 nad  pyd    4791296 Nov  1 15:08 python3.4dm*
-rwxr-xr-x  1 nad  pyd       2041 Nov  1 15:08 python3.4dm-config*
-rwxr-xr-x  1 nad  pyd        245 Nov  1 15:08 pyvenv-3.4*

Now after "make install" is run:

lrwxr-x---  1 nad  pyd          8 Nov  1 15:21 2to3@ -> 2to3-3.4
-rwxr-xr-x  1 nad  pyd        110 Nov  1 15:21 2to3-3.4*
-rw-r-----  1 nad  pyd        687 Nov  1 15:19 easy_install
-rw-r-----  1 nad  staff      355 Nov  1 15:19 easy_install-3.3.pya
-rw-r-----  1 nad  pyd        687 Nov  1 15:19 easy_install-3.4
-rw-r-----  1 nad  staff      347 Nov  1 15:19 easy_install.pya
lrwxr-x---  1 nad  pyd          7 Nov  1 15:21 idle3@ -> idle3.4
-rwxr-xr-x  1 nad  pyd        108 Nov  1 15:21 idle3.4*
-rw-r-----  1 nad  pyd        659 Nov  1 15:19 pip
-rw-r-----  1 nad  pyd        659 Nov  1 15:19 pip3
-rw-r-----  1 nad  pyd        659 Nov  1 15:19 pip3.4
lrwxr-x---  1 nad  pyd          8 Nov  1 15:21 pydoc3@ -> pydoc3.4
-rwxr-xr-x  1 nad  pyd         93 Nov  1 15:21 pydoc3.4*
lrwxr-x---  1 nad  pyd          9 Nov  1 15:21 python3@ -> python3.4
lrwxr-x---  1 nad  pyd         16 Nov  1 15:21 python3-config@ -> python3.4-config
-rwxr-xr-x  2 nad  pyd    4791296 Nov  1 15:20 python3.4*
lrwxr-x---  1 nad  pyd         18 Nov  1 15:21 python3.4-config@ -> python3.4dm-config
-rwxr-xr-x  2 nad  pyd    4791296 Nov  1 15:20 python3.4dm*
-rwxr-xr-x  1 nad  pyd       2041 Nov  1 15:21 python3.4dm-config*
lrwxr-x---  1 nad  pyd         10 Nov  1 15:21 pyvenv@ -> pyvenv-3.4
-rwxr-xr-x  1 nad  pyd        245 Nov  1 15:21 pyvenv-3.4*

The problem I see here is that pip is unconditionally installing both a pip and a pip3 script along with the versioned script (pip3.4).  Setuptools also has the same issue (along with the wonky .pya scripts which I think should be Windows only).  For system installs, pip, setuptools, and ensurepip should support the equivalent of "altinstall" and "install" options, with the former only installing fully-versioned names and the latter adding "3" names and, to be consistent, neither should install the totally unversioned links for Python 3, so no "pip" or "easy_install".  Third-party packagers solve the conflict between Py2 and Py3 scripts in various ways, like providing some administrative command (e.g. debian "update-alternatives" or Macports "port select").  For virtual environments, the user has complete control over the bin directory and the current behavior of pip and easy_install is OK there (and would be introduce an incompatibility if the default were to change).  ensurepip should be conservative about this.  Perhaps the way to implement it is to introduce something like a non-default --alt (name TBD) option to both setuptools and pip (for backwards compatibility) and have ensurepip by default always install setuptools and pip with --alt unless installing into a virtual environment or with a "--makedefault" (name TBD) option?  It would be rather nasty for the default ensurepip to wipe out already installed versions of pip and easy_install for Python 2 (yes, you would need to have the appropriate privilege as well) in a shared bin directory, like /usr/local/bin or /usr/bin.  FTR, the OS X installer build script could work around the current behavior.
History
Date User Action Args
2013-11-01 23:52:34ned.deilysetrecipients: + ned.deily, loewis, ncoghlan, larry, tshepang, dstufft
2013-11-01 23:52:34ned.deilysetmessageid: <1383349954.67.0.462385670935.issue19406@psf.upfronthosting.co.za>
2013-11-01 23:52:34ned.deilylinkissue19406 messages
2013-11-01 23:52:33ned.deilycreate