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

[Monty Taylor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 09/27/2013 10:50 PM, Donald Stufft wrote:
> 
> On Sep 27, 2013, at 9:20 PM, Brett Cannon <brett at python.org 
> <mailto:brett at python.org>> wrote:
> 
>> 
>> 
>> 
>> On Fri, Sep 27, 2013 at 5:16 PM, Zachary Ware 
>> <zachary.ware+pydev at gmail.com
>> <mailto:zachary.ware+pydev at gmail.com>> wrote:
>> 
>> On Fri, Sep 27, 2013 at 3:29 PM, Donald Stufft <donald at stufft.io 
>> <mailto: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+

I'm in favor of whatever causes it to get available in 2.7/3.3 in a
way that's predictable. OpenStack is both very highly invested in pip
installation of software and dependencies and also seemingly
maniacally obsessed with continuing to support the older pythons
people have. (eek, we have to support 2.6 until a new RHEL comes out)

To that end, we wind up bootstrapping into pip via distro packages,
but then it's too old, so then people pip install -U pip - systemwide,
so then pip gets broken on redhat and weird on ubuntu because of fail,
and then they get angry and start yelling and I have to go hide in a hole.

If we could start, in tooling, depending on some predictable manner
other than the distros to bootstrap into a sensible and modern pip, I
believe my life would be so much better that I might grow a herd of
unicorns.

Monty
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlJGRTgACgkQ2Jv7/VK1RgF3PQCg18X5gBomDNvI0zTUcFJyN5As
misAoOcnFdJYpAM8ur/lfDhKFGxh4VmQ
=BuJf
-----END PGP SIGNATURE-----