[Distutils] PEP 439 and pip bootstrap updated

[Daniel Holth]

I hope we will also arrive at a pip that doesn't need to be individually
installed per venv...
On Jul 11, 2013 6:13 PM, "Paul Moore" <p.f.moore at gmail.com> wrote:

> +1 Explicit is better than implicit.
>
> Amending venv to automatically install pip (as suggested by Donald) may be
> worth doing. I'm +0 on that (with the proviso that there's a --no-pip
> option in that case). OTOH, the venv module is very extensible and writing
> your own wrapper to import getpip and call bootstrap is pretty much trivial.
>
> On 11 July 2013 22:48, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>> (Oops, started this yesterday, got distracted and never hit send)
>>
>> On 11 July 2013 11:09, Richard Jones <richard at python.org> wrote:
>> >
>> > On 11 July 2013 06:50, Paul Moore <p.f.moore at gmail.com> wrote:
>> > > I think "python -m pip" should be the canonical form (used in
>> documentation,
>> > > examples, etc). The unittest module has taken this route, as has
>> timeit.
>> > > Traditionally, python-dev have been lukewarm about the -m interface,
>> but its
>> > > key advantage is that it bypasses all the issues around versioned
>> > > executables, cross-platform issues, the general dreadfulness of script
>> > > wrappers on Windows, etc, in one fell swoop.
>> >
>> > "python -m pip" does make the bootstrapping a more complex proposition
>> > - the stdlib would have to have something called "pip" that could be
>> > overridden (while it is actually *running*) by something installed in
>> > site-packages. Not easy.
>>
>> I was thinking about that, and I'm wondering if the most sensible option
>> may be to claim the "getpip" name on PyPI for ourselves and then do the
>> following:
>>
>> 1. Provide "getpip" in the standard library for 3.4+ (and perhaps in a
>> 2.7.x release)
>> 2. Install it to site-packages in the "Python launcher for Windows"
>> installer for earlier versions
>>
>> getpip would expose at least one function:
>>
>>     def bootstrap(index_url=None, system_install=False):
>>         ...
>>
>> And executing it as a main module would either:
>>
>> 1. Do nothing, if "import pip" already works
>> 2. Call bootstrap with the appropriate arguments
>>
>> That way, installation instructions can simply say to unconditionally do:
>>
>>     python -m getpip
>>
>> And that will either:
>>
>> 1. Report that pip is already installed;
>> 2. Bootstrap pip into the user environment; or
>> 3. Emit a distro-specific message if the distro packagers want to push
>> users to use the system pip instead (since they get to patch the system
>> Python and can tweak the system getpip however they want)
>>
>> The 2.7 change would then be to create a new download that bundles the
>> Windows launcher into the Windows installer.
>>
>> Users aren't stupid - the problem with the status quo is really that the
>> bootstrapping instructions are annoyingly complicated and genuinely
>> confusing, not that an explicit bootstrapping step is needed in the first
>> place.
>>
>> Cheers,
>> Nick.
>>
>>
>>
>>
>> >
>> > Thanks everyone for your brilliant feedback and discussion - I look
>> > forward to being able to say something sensible about Windows in the
>> > PEP :-)
>>
>>
>> >
>> >
>> >
>> >      Richard
>>
>>
>> --
>> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>> On 11 July 2013 06:50, Paul Moore <p.f.moore at gmail.com> wrote:
>> > I think "python -m pip" should be the canonical form (used in
>> documentation,
>> > examples, etc). The unittest module has taken this route, as has timeit.
>> > Traditionally, python-dev have been lukewarm about the -m interface,
>> but its
>> > key advantage is that it bypasses all the issues around versioned
>> > executables, cross-platform issues, the general dreadfulness of script
>> > wrappers on Windows, etc, in one fell swoop.
>>
>> "python -m pip" does make the bootstrapping a more complex proposition
>> - the stdlib would have to have something called "pip" that could be
>> overridden (while it is actually *running*) by something installed in
>> site-packages. Not easy.
>>
>> Thanks everyone for your brilliant feedback and discussion - I look
>> forward to being able to say something sensible about Windows in the
>> PEP :-)
>>
>>
>>      Richard
>>
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130711/dd940b04/attachment-0001.html>