[Distutils] PEP 439 and pip bootstrap updated

[Daniel Holth]

+1. No magic side effects will make everyone happier.
On Jul 11, 2013 5:48 PM, "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/ed304562/attachment.html>