[Distutils] Current status of PEP 439 (pip boostrapping)

Brett Cannon brett at python.org
Sat Jul 13 15:35:08 CEST 2013

On Sat, Jul 13, 2013 at 2:29 AM, Ned Deily <nad at acm.org> wrote:

> In article <55B209B3-9576-4CF0-B58C-2A1E692AFFF1 at stufft.io>,
>  Donald Stufft <donald at stufft.io> wrote:
> > On Jul 13, 2013, at 1:31 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > > 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.
> Off the top of my head, including a copy of pip as a pre-installed
> global site-package seems like a very reasonable suggestion.   For the
> python.org OS X installer, it should be no problem to implement.  It
> would be equally easy to implement for future 2.7 and 3.3 maintenance
> releases.

Does Apple just install the python.org OS X installer for distribution, or
do they build their own thing? My only worry is that Apple will not get the
message about including pip and we will end up with an odd skew on OS X
(I'm not worried about Linux distros as they all seem to follow Python
development closely).

And we obviously need to know if Martin is okay with doing something
similar on Windows.

> > We could simply check it into the site-packages inside the CPython source
> > tree could we not? *Not* providing a bootstrap script and merely
> checking it
> > into the default site-packages means it's available for everyone. No
> matter
> > how python installed. If Linux packagers really don't want it installed
> by
> > default they could simply just remove it and either install it along with
> > Python, or continue to keep it how it is today as a separate package?
> This sounds an unnecessary complication.  I suspect that there is a
> small minority of users who actually build Python from source.  And they
> should know what they are doing.  I believe most users either use a
> distribution-provided Python (via their OS) or a third-party package
> provider (including python.org binary installers and their derivatives).
> The OS distributors are going to do what they currently do; the only
> change needed is to persuade them to include their pip package as a
> mandatory dependency.  Trying to hack the Python source build process to
> include a copy of pip is just not worth the effort.

And I doubt that will take much convincing, e.g. ActiveState includes their
own installer -- PyPM -- in their distro.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130713/2b1cfeec/attachment.html>

More information about the Distutils-SIG mailing list