On Jul 13, 2013, at 6:46 AM, Brett Cannon wrote: > > > > On Sat, Jul 13, 2013 at 1:31 AM, Nick Coghlan <ncogh...@gmail.com> 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. > > But is it going to make a difference? If we shift to using included copies of > pip in binary installers over a bootstrap I say leave out the bootstrap as > anyone building from source should know how to get pip installed on their > machine or venv. > > The only reason I see it worth considering is if pyvenv starts bootstrapping > pip and we want to support the case of pip not being installed. But if we are > including it in the binary installer and are going to assume it's available > through OS distros, then there isn't a need to as pip can then install pip > for us into the venv and skip any initial pip bootstrap. If pip isn't found > we can simply either point to the docs in the failure message or print out > the one-liner it takes to install pip (and obviously there can be a --no-pip > flag to skip this for people who want to install it manually like me who > build from source). > > IOW I think taking the worldview in Python 3.4 that pip will come installed > with Python unless you build from source negates the need for the bootstrap > script beyond just saying ``curl https://pypi.python.org/get-pip.py | > python`` if pip isn't found.
This is highly unhelpful for dealing with systems automation. For the foreseeable future, the bulk of Python 3.4 installations will either be source installs, or homegrown packages based on source installs. The bundled pip doesn't need to be included with, say, an hg clone that you then build and install, but it does have to come with an install from an official release source tarball. --Noah
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
