On Sep 27, 2013, at 9:20 PM, Brett Cannon <br...@python.org> wrote: > > > > On Fri, Sep 27, 2013 at 5:16 PM, Zachary Ware <zachary.ware+py...@gmail.com> > wrote: > On Fri, Sep 27, 2013 at 3:29 PM, Donald Stufft <don...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
