[Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?
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.
> > [... easy_install on OS X ...]
> So this is an interesting question. On one hand I would say we shouldn't be
> installing easy_install as that feels very user facing to me and the fact
> 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 easy_install (perhaps for Egg support) won't be
> able too (unless perhaps something is released on PyPI that restores the
> easy_install 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
> 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
> 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
> 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.
nad at acm.org
More information about the Python-Dev