[Distutils] PEP 453 Round 2 - Explicit bootstrapping of pip in Python installations

[Nick Coghlan]

On 16 September 2013 22:08, Oscar Benjamin <oscar.j.benjamin at gmail.com> wrote:
> On 16 September 2013 12:27, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> On 16 Sep 2013 19:55, "Oscar Benjamin" <oscar.j.benjamin at gmail.com> wrote:
>>>
>>> I still don't understand why this is preferable to just shipping a
>>> recent stable pip/setuptools and providing instructions to update
>>> post-install. That would surely be a lot simpler not just to implement
>>> but for others to understand.
>>>
>>> If I'm happy to use the bundled version of pip then why do I need to
>>> do anything to make it usable after having already run the installer?
>>> If I want the new version then why is 'py -m getpip' better than 'py
>>> -m pip install -U pip'?
>>
>> You don't, the installer bootstraps it for you. Running it explicitly should
>> only be needed when building from source, or bootstrapping a previously
>> pip-free virtual environment.
>
> Oh okay. So basically the normal thing is that pip just gets installed
> automatically when you install Python. For most people the whole of
> the "explicit bootstrapping" described in the PEP is an implementation
> detail that occurs *implicitly* during installation? The only point of
> relevance from a user perspective is that running the installer
> without a network connection leaves you with an older version of
> pip/setuptools.
>
>> The complicated bootstrapping dance is both to make pip easy to leave out if
>> people really don't want it and to avoid the CPython platform installers and
>> pip getting into a fight about who is responsible for the files.
>
> Surely this is only relevant for people using the installers since if
> you're capable of building CPython from source then you should be
> plenty capable of installing pip/setuptools from source as well.
> Likewise if you're installing via a distro package manager then you're
> not going to use this bootstrapping script. If this is just for the
> Windows and OSX installers then can they not just have a tickbox for
> installing the bundled pip and another tickbox for updating it (both
> on by default)? If you need to update it after installation then you
> can just use pip to update itself.
>
> Who, apart from the Windows and OSX installers, is going to use this
> bootstrap script?

As noted in the PEP, pyvenv will use it to add pip to virtual
environments by default (with an option to turn it off when creating
the venv). The only case where we expect getpip *won't* be used is for
system installs of Python on Linux distributions (since the system
package manager will likely provide it instead).

> When you say that pip and the installer could get into a fight about
> responsibility do you mean for uninstallation? Presumably if you're
> uninstalling Python then you also want to uninstall the associated pip
> installation so it's fine for the installer to just delete everything
> to do with pip anyway right?

No, it's a problem when you install a new maintenance version of
CPython over an existing installation. With getpip, we can treat that
like any other case of running getpip when pip is already installed.
With a bundled pip, the OS installer will try to overwrite the
existing installation (which may be a downgrade if you previously used
pip to upgrade itself to a more recent version than the bundled one).

Separating the two (installer owns getpip, pip owns pip) makes a lot
of competing upgrade related issues just go away.

The other aspect is a social one, though. The bootstrapping dance
helps make it clearer that only getpip is developed directly under the
normal CPython governance model - pip is developed by
PyPA/distutils-sig and merely shipped with CPython.

However, I just noticed that the PEP *doesn't* currently specify the
effect of running "python -m getpip" when pip is already installed. I
believe it should attempt to upgrade pip, so that in the normal course
of events (i.e. just installing CPython maintenance releases without
manually upgrading pip), then pip will be automatically upgraded to
the latest version each time CPython itself is updated.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia