On Jul 12, 2013, at 10:31 PM, Nick Coghlan wrote: > In addition to the long thread based on Richard's latest set of updates, I've > also received a few off-list comments on the current state of the proposal. > So, I figured I'd start a new thread summarising my current point of view and > see where we want to go from there. > > 1. However we end up solving the bootstrapping problem, I'm *definitely* a > fan of us updating pyvenv in 3.4 to ensure that pip is available by default > in new virtual environments created with that tool. I also have an idea for a > related import system feature that I'll be sending to import-sig this > afternoon (it's a variant on *.pth and *.egg-link files that should be able > to address a variety of existing problems, including the one of *selectively* > making system and user packages available in a virtual environment in a > cross-platform way without needing to copy them) > > 2. While I was originally a fan of the "implicit bootstrapping on demand" > design, I no longer like that notion. While Richard's bootstrap script is a > very nice piece of work, the edge cases and "neat tricks" have built up to > the point where they trip my "if the implementation is hard to explain, it's > a bad idea" filter. > > Accordingly, I no longer think the implicit bootstrapping is a viable option. > > 3. That means there are two main options available to us that I still > consider viable alternatives (the installer bundling idea was suggested in > one of the off list comments I mentioned): > > * an explicit bootstrapping script > * bundling a *full* copy of pip with the Python installers for Windows and > Mac OS X, but installing it to site-packages rather than to the standard > library directory. That way pip can be used to upgrade itself as normal, > rather than making it part of the standard library per se. This is then > closer to the "bundled application" model adopted for IDLE in PEP 434 (we > could, in fact, move to distributing idle the same way). > > I'm currently leaning towards offering both, as we're going to need a tool > for bootstrapping source builds, but the simplest way to bootstrap pip for > Windows and Mac OS X users is to just *bundle a copy with the binary > installers*. So long as the bundled copy looks *exactly* the way it would if > installed later (so it can update itself), then we avoid the problem of > coupling the pip update cycles to the standard library feature release cycle. > The bundled version can be updated to the latest available versions when we > do a Python maintenance release. > > For Linux, if you're using the system Python on a Debian or Fedora > derivative, then "sudo apt-get python-pip" and "sudo yum install python-pip" > are both straightforward, and if you're using something else, then it's > unlikely getting pip bootstrapped using the bootstrap script is a task that > will bother you :) > > The "python -m getpip" command is still something we will want to provide, as > it is useful to people that build their own copy of Python from source. > > The bundling idea will obviously need to be discussed with the installer > builders, and on python-dev in general, but that was always going to be the > case for this PEP anyway (since it *does* touch CPython directly, rather than > just being related to the packaging ecosystem). It achieves the aim of > allowing people to assume some version of pip will be present on Python 3.4+ > installations (or readily available in the case of Linux), while avoiding the > problem of coupling pip updates to major Python version updates.
As someone that has otherwise remained silent on this thread but was talking with people off-list I probably owe them a public +1 for bundling pip as a semi-new category of non-stdlib-but-included project. This would bring us in line with other tools like gem and npm which work out of the box and gives the user experience people want. Care would have to be paid to make sure the final pip binary ends up in the right filename, much in the same way as we do python -> python2 -> python 2.7 and such, but this is a solvable problem. How linux distros adapt to this is certainly another question, but I would absolutely advocate to packagers that installing the main python package results in a working pip install, regardless of how that is accomplished. As someone that has to write system management scripts to install and configure Python, being able to count on both pip and pyenv as standard tools in standard places is near-mind-blowingly awesome (give or take that it would be many years unt il I could reasonably assume 3.4 as the default python, but a man can dream). While the getpip module is interesting in a few use cases, it is vastly more valuable to me that we focus on the user experience of the majority of Python developers and deployments, and this is somewhere that Ruby and Node are getting it right in having the package tool simply be there by default. Bundling also addresses the myriad ways in which downloading on the fly either during install or afterwards is error-prone and may result in environment fragmentation (servers that don't have internet access, PyPI outages, etc). --Noah _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
