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

Brett Cannon brett at python.org
Sat Jul 13 15:31:01 CEST 2013

On Sat, Jul 13, 2013 at 8:25 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 13 Jul 2013 19:05, "Paul Moore" <p.f.moore at gmail.com> wrote:
> >
> > On 13 July 2013 06:31, Nick Coghlan <ncoghlan at gmail.com> wrote:
> >>
> >> * 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).
> >
> >
> > How robust is the process of upgrading pip using itself? Specifically on
> Windows, where these things typically seem less reliable.
> >
> > Personally, I have never upgraded pip using itself, because I only ever
> install pip in virtualenvs, which don't have a lifespan as long as a pip
> release cycle :-) It would be easy to imagine a new pip release resulting
> in a *lot* of bugs raised against Python (rather than pip) saying that the
> upgrade fails. And of course if an upgrade fails, we can't just release a
> new version of pip that fixes the issue, because it's the *old* version
> that is installed and has to do the upgrade. So there's manual fiddling to
> do. Not a good experience for Python users.
> >
> > My current workflow is to have absolutely nothing installed in the
> system Python and use virtualenvs for everything. This is a bit extreme,
> but the issues I've hit in the past when package management has gone wrong
> have made me very cautious.
> >
> > If the pip upgrade process is rock-solid, this isn't an issue, but I'm
> not sure that it is, myself.
> I think we need to flip the dependencies so that pip as the installer has
> all the essential code for installation from PyPI and then setuptools and
> distlib depend on that pip infrastructure. No need to add anything to the
> standard library prematurely when we can add it to pip instead.

+1 on the inversion. I don't know what that will do to pip, it makes sense
to have the installer self-contained and the packaging/building libraries
be something that you grab using the installer. Having to grab the
packaging infrastructure to get an installer is the more painful route.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130713/ce0df67a/attachment-0001.html>

More information about the Distutils-SIG mailing list