On 19 Aug 2013 07:54, "Donald Stufft" <don...@stufft.io> wrote:
>
> I'm only briefly checking my email before going back to sleep but just
thought I'd mention I have a successor to PEP439 mostly written and I was
planning on finishing it up based on some feedback i'd gotten and
publishing it this week.
>
> More specific response when I'm not half asleep.
Donald sent me the preliminary draft last week, so I can share the short
version of the proposal:
* Bootstrap included in the standard library, executable as "python -m
getpip". This ensures a clear distinction between files managed by the
system installer (i.e. getpip) and those managed by pip (including pip
itself)
* Installs the bundled copy of pip by default, but has an option to do a
network install of the latest from PyPI
* Updates of the installed version use "pip install --upgrade pip" as normal
* Bundled version inside getpip will be updated when pip is updated (so
CPython maintenance releases may have newer versions of pip)
* If you build from source, you need to run the bootstrap explicitly to get
pip
* Windows and Mac OS X installers will bootstrap the bundled pip by default
(opt-out) with a network update option (opt-in)
The following two points aren't in Donald's PEP yet, and are the main
reason the initial draft wasn't published more widely:
* We'll ask the Linux distros to define a circular runtime dependency
between python and python-pip (I spoke to Toshio about that at Flock last
weekend and Fedora is amenable, but we haven't asked any Debian or Ubuntu
folks yet)
* pyvenv will install pip by default (with an option to opt-out)
The main open question is how we uninstall Python without leaving pip
managed files around. If an appropriate command doesn't already exist, pip
may need to grow a "python -m pip uninstall --all --force" command that the
Python uninstallers can invoke.
The bootstrap will also need to be able to control whether or not script
wrappers are installed and the name they use and/or key them off
sys.implementation somehow.
Cheers,
Nick.
>
> On Aug 19, 2013, at 7:31 AM, Paul Moore <p.f.mo...@gmail.com> wrote:
>
> > While debate on PEP 439 has died down, I've been thinking about what it
actually means to end users for Python to bundle pip. If we have an
explicit bootstrapping command like get_pip, how much practical benefit is
there for that to be bundled vs having a well-known location for such a
script (which is more or less what we have now)?
> >
> > Also, there is the whole question of how much we want to "lock down"
what pip currently provides, as official functionality. (Particularly given
the renewed energy around projects like distlib/distil, etc).
> >
> > I'd like to propose that as a first step, we agree and document a *user
interface* that will be officially supported going forward. It would be
based on (a subset of) the pip interface, so that a "bundle pip" strategy
is still the immediate way forward, but by standardising the interface
rather than the implementation, we retain the option to change things
behind the scenes if, for example, distil suddenly takes over the world.
> >
> > Users get the benefit of a properly sanctioned "one true way" to manage
packages. And we reserve enough flexibility that we don't accidentally
accept constraints that are stronger than we'd like and stifle innovation.
> >
> > To be specific, what I propose is that we agree on the following:
> >
> > 1. Python installations provide a bootstrap command (tentatively
"python -m get_pip", I'm not sure this needs to be directly executable, the
-m interface is probably fine). This command may be a no-op if for example
we opt for full bundling (and it will always be a no-op after the first
run).
> > 2. Once bootstrapped, Python will provide a "pip" command (or pip3?)
accessible whenever the "python" command is available (worded this way
because the Windows installer doesn't put "python" on PATH by default).
> > 3. A specific subset of the current pip interface is provided (to be
documented). I'd suggest we need a minimum of pip install, pip list, pip
uninstall, pip install -U (for upgrades). I don't know what proportion of
the rest of the pip API (various options, requirement files, environment
variables and ini files) we want to lock down - I suggest we start minimal
and add items as needed.
> > 4. We may want to add a separate note that "python -m pip" will do the
same as the "pip" command, and may be needed to self-upgrade the pip
command ("python -m pip -U pip").
> >
> > We can note for 3.4 that the pip command will be implemented using the
current pip project, and so all of the other features of pip will be
available, but with the proviso that any interfaces not explicitly
mentioned in the standard documentation may be changed or removed as pip
changes, and are not protected by Python's compatibility rules. That gives
users a reasonable level of stability, while still allowing us the room to
innovate.
> >
> > Does this sound reasonable? It may be obvious to everyone but me that
this is what we're expecting - or I may even be proposing *more* than
people expect. But I think something along the lines of an "interface over
implementation" definition like this would be reasonable.
> >
> > If this is a useful proposal and no-one else is already working on
something similar, I'm willing to write this up as a PEP.
> >
> > Paul.
> > _______________________________________________
> > Distutils-SIG maillist - Distutils-SIG@python.org
> > http://mail.python.org/mailman/listinfo/distutils-sig
>
>
> -----------------
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
DCFA
>
>
> _______________________________________________
> 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
