On 16 Sep 2013 19:55, "Oscar Benjamin" oscar.j.benjamin@gmail.com wrote: >
On 15 September 2013 16:33, Donald Stufft donald@stufft.io wrote:
So there've been a number of updates to PEP453, so i'm posting it here again for more discussion:
Explicit Bootstrapping
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
callable named bootstrap() as well as offer direct execution via
python -m getpip. Options for installing it such as index server,
installation location (--user, --root, etc) will also be
available
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
contact PyPI.
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'?
You don't, the installer bootstraps it for you. Running it explicitly should only be needed when building from source, or bootstrapping a previously pip-free virtual environment.
The complicated bootstrapping dance is both to make pip easy to leave out if people really don't want it and to avoid the CPython platform installers and pip getting into a fight about who is responsible for the files.
Recommendations for Downstream Distributors
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.
- This may take the form of separate packages with dependencies on each other so that installing the Python package installs the pip package and installing the pip package installs the Python package.
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.
Fedora is fine with it (we discussed it at Flock last month), while Ubuntu (and Debian?) already splits out a "python-core" package for inclusion on the installation media, so should be fine with having the full python have a circular dependency with pip.
Other distros will be free to make their own decisions, but I believe they all already tolerate this bundling approach inside virtualenv.
Windows and Mac OS X users are intended as the main beneficiaries though - bootstrapping pip with yum, apt, etc is much easier than bootstrapping it on either of those platforms.
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.
Yep, but there are plenty of options available to do that, and the better ones work even if users download and install pip directly.
Our target audience here is the beginning enthusiast (regardless of OS). Sophisticated users (including admins that want to lock their system down) can still do so if they really want to.
Cheers, Nick.
> >
Oscar
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig