[Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement? (original) (raw)

Ned Deily nad at acm.org
Tue Sep 24 06:32:37 CEST 2013

In article <44F4E1F8-5533-45A7-810E-B9C13530E9DD at stufft.io>, Donald Stufft <donald at stufft.io> wrote:

On Sep 23, 2013, at 7:34 PM, Ned Deily <nad at acm.org> wrote: > [... license implications ...]

As far as I know the certificate bundle is licensed under either GPL, MPL, or LGPL. However there is debate about wether a CA bundle can be licensed at all (see https://github.com/pypa/pip/pull/971). Pip also includes some code taken from other libraries however everything is licensed as either 1, 2, or 3 clause BSD (besides the aforementioned certificates). I can't think of us being ok with adding a copyleft license such as GPL so code we bring in will likely be restricted to things like BSD.

IANAL, but I think it would be good if, at least, the setuptools license were clearer and the LGPL reference for the cert bundle was changed. It might be a good idea to get an opinion from Van Lindberg. But I'm happy to defer to Martin's judgement on this.

> [... easyinstall on OS X ...]

So this is an interesting question. On one hand I would say we shouldn't be installing easyinstall as that feels very user facing to me and the fact that setuptools is being installed is an implementation detail. On the other hand if we put in stub commands that just simply direct the user to use pip then people who want to use easyinstall (perhaps for Egg support) won't be able too (unless perhaps something is released on PyPI that restores the easyinstall commands?)

I was thinking that, in the latter case, those users who really want to use easy_install could be told to just use pip to install a PyPI version of setuptools which would replace the stub commands with the real things - assuming that works.

> [... implementation plan ...]

To further expand upon my original answer, I'm volunteering to do the initial work on the ensurepip library, the scripts that will automated the ongoing maintenance work, and the back porting of both of the above. I can also attempt to do the OSX Installer and Windows installer but I have zero idea how the installers actually function so it's probably better for someone else to do that. Since it sounds like you're willing to do the work for the OSX installer that saves me from having to flail around trying to figure out how to do that part, so hopefully MvL or someone can do the same with the Windows installer. I'm not sure what needs done outside of the up front work, do I just propose changes to PEP 101? Do I make a whole new PEP? Is there more than just updating PEP 101?

I think the thing to do is get review buy-in from the release managers for the affected active releases (2.7.x = Benjamin, 3.3.x = Georg, 3.4.x = Larry) and let them worry about updating PEP 101. The key point is that this PEP is implicitly adding some new responsibilities for the release team; I think they just need to be explicit.

-- Ned Deily, nad at acm.org

More information about the Python-Dev mailing list