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.mo...@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 <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
