+1. No magic side effects will make everyone happier. On Jul 11, 2013 5:48 PM, "Nick Coghlan" <ncogh...@gmail.com> wrote:
> (Oops, started this yesterday, got distracted and never hit send) > > On 11 July 2013 11:09, Richard Jones <rich...@python.org> wrote: > > > > On 11 July 2013 06:50, Paul Moore <p.f.mo...@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 | ncogh...@gmail.com | Brisbane, Australia > On 11 July 2013 06:50, Paul Moore <p.f.mo...@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@python.org > http://mail.python.org/mailman/listinfo/distutils-sig > >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig