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

[Ned Deily]

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 
> 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 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 
> 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