On 15 September 2013 16:33, Donald Stufft firstname.lastname@example.org wrote:
So there've been a number of updates to PEP453, so i'm posting it here again for more discussion:
An additional module called
getpip will be added to the standard library
whose purpose is to install pip and any of its dependencies into the
appropriate location (most commonly site-packages). It will expose a single
bootstrap() as well as offer direct execution via
python -m getpip. Options for installing it such as index server,
installation location (
--root, etc) will also be
to enable different installation schemes.
It is believed that users will want the most recent versions available to be installed so that they can take advantage of the new advances in packaging. Since any particular version of Python has a much longer staying power than a version of pip in order to satisfy a user's desire to have the most recent version the bootstrap will contact PyPI, find the latest version, download it, and then install it. This process is security sensitive, difficult to get right, and evolves along with the rest of packaging.
Instead of attempting to maintain a "mini pip" for the sole purpose of
installing pip the
getpip module will, as an implementation detail,
include a private copy of pip and its dependencies which will be used to
discover and install pip from PyPI. It is important to stress that this
private copy of pip is only an implementation detail and it should not
be relied on or assumed to exist.
Not all users will have network access to PyPI whenever they run the
bootstrap. In order to ensure that these users will still be able to
bootstrap pip the bootstrap will fallback to simply installing the included
copy of pip. The pip
--no-download command line option will be supported
to force installation of the bundled version, without even attempting to
This presents a balance between giving users the latest version of pip, saving them from needing to immediately upgrade pip after bootstrapping it, and allowing the bootstrap to work offline in situations where users might already have packages downloaded that they wish to install.
I still don't understand why this is preferable to just shipping a recent stable pip/setuptools and providing instructions to update post-install. That would surely be a lot simpler not just to implement but for others to understand.
If I'm happy to use the bundled version of pip then why do I need to do anything to make it usable after having already run the installer? If I want the new version then why is 'py -m getpip' better than 'py -m pip install -U pip'?
A common source of Python installations are through downstream distributors such as the various Linux Distributions [#ubuntu]_ [#debian]_ [#fedora]_, OSX package managers [#homebrew]_, or python specific tools [#conda]_. In order to provide a consistent, user friendly experience to all users of Python regardless of how they attained Python this PEP recommends and asks that downstream distributors:
Ensure that whenever Python is installed pip is also installed.
Do not remove the bundled copy of pip.
Are distros really going to be okay with this idea? Many of them have CPython in their base install so you're basically asking that they always ship a parallel package management system that is outside of their control.
Personally I think that it's unfortunate that distro package managers don't have a --user option like pip does but I've always assumed that they had some good reason for not wanting any old user to be able to easily install things without admin/root privileges. This would break that arrangement since any user would be able to use 'pip install --user' to install anything from PyPI. I imagine that lots of deployment sites would want to disable this even if the distro has it enabled by default.