On 16 September 2013 22:08, Oscar Benjamin firstname.lastname@example.org wrote:
On 16 September 2013 12:27, Nick Coghlan email@example.com wrote: >
On 16 Sep 2013 19:55, "Oscar Benjamin" firstname.lastname@example.org 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.
-- Nick Coghlan | email@example.com | Brisbane, Australia