Ned Deily added the comment: 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 sho uld 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue19406> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
