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

[Donald Stufft]

On Sep 27, 2013, at 9:20 PM, Brett Cannon <brett at python.org> wrote:

> 
> 
> 
> On Fri, Sep 27, 2013 at 5:16 PM, Zachary Ware <zachary.ware+pydev at gmail.com> wrote:
> On Fri, Sep 27, 2013 at 3:29 PM, Donald Stufft <donald at stufft.io> wrote:
> >
> <snip>
> >
> > If it lives in the source tree how are you going to provent it from existing when someone installs on Linux? OSX? One of the BSDs?
> 
> If someone is building their own Python from source--regardless of
> platform--they're obviously going to have _ensurepip available one way
> or another, and such users will need to have it available to match the
> capabilities of the installer (or create their own).  But if you're
> building your own Python, you should already know enough about what's
> going on to know when and whether _ensurepip should be used and how.
> On the other hand, when you use an installer (be it Windows, OSX, or
> otherwise), you really only need _ensurepip one time, ever: at install
> time.  Even then, you don't actually need to know anything about
> _ensurepip at all, just whether to check the box or not.  If you
> decide you need it later, you can always re-install.
> 
> > It seems to me your [Terry's] proposal is to add the _ensurepip module… except when they install it via Windows installer.
> 
> The way I read Terry's proposal, it is to never add the _ensurepip
> *module*, but to use (or make available, whichever makes sense in a
> given case) the _ensurepip *script* when it is requested at
> install-time: specifically, put _ensurepip.py in Tools/scripts, PC/,
> Mac/, or really anywhere but Lib/ so that builders can find it, but
> Python can't.  In other words, don't make "import _ensurepip" possible
> out of the box, and a lot of the "don't add new features in
> maintenance releases" blockade disappears, because you aren't actually
> adding any new capability to Python itself or its standard library.
> 
> Of course, this proposal only applies to 2.7/3.3.  Since _ensurepip
> will be used for venv as well as initial install in 3.4, it should be
> a full-blown stdlib module in that version, probably even without the
> leading underscore.
> 
> That's how I read the proposal as well. If that works then great, otherwise naming it _ensurepip in 2.7/3.3 should be enough to warn anyone that they are playing with fire. I think Martin, Ned, etc. would need to weigh in on whether it's at all an issue having the ensurepip script somewhere that doesn't get installed but executable from the installer is at all an issue. For source it can just be in Tools for 2.7/3.3 if that's the route chosen.
> 
> Regardless, one of these two options is enough and I suspect we can stop debating and let Martin make his BDFAP decision.


Yes, no matter which way the decision for 2.7 and 3.3 goes the proposal is for "ensurepip" in 3.4+

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130927/ce587a9b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130927/ce587a9b/attachment.sig>