On 15 September 2013 16:33, Donald Stufft donald@stufft.io wrote: [...]
pip currently depends on
setuptools to handle metadata generation
during the build process, along with some other features. While work is
ongoing to reduce or eliminate this dependency, it is not clear if that
work will be complete for pip 1.5 (which is the version likely to be
bundled with Python 3.4.0).
Might be better worded as "(which is the version likely to be current when Python 3.4.0 is released)",
This PEP proposes that, if pip still requires it,
setuptools will be
bundled along with pip itself, and thus installed when running
python -m getpip.
Do you mean "thus installed"? Surely the current version from PyPI will be installed except in --no-download cases?
Actually, I'd be inclined to avoid the use of the word "bundled". getpip has an "internal copy" of pip, which users aren't supposed to care about except for the fact that it's the "static version included for offline installation", and there's also the "current version on PyPI" which is what is normally installed. I don't think that any of the 3 quoted terms really corresponds to "bundled" in the sense that people will expect it to mean.
Updating the bundled pip
[..]
This means that maintenance releases of the CPython installers will include
an updated version of the getpip bootstrap module.
Is this solely the copy of pip that will be updated, or if there are logic changes in getpip itself (I can't immediately think of any that might be added) will they be included as well?
While the Windows installer was updated in Python 3.3
to make python
available on the PATH,
Correction: it was updated to optionally make Python available, and the option is off by default.
no such change was made to include the scripts directory. This PEP proposes that this be changed to also add the scripts directory.
Without this change, the most reliable way to invoke pip on Windows (without
tinkering with paths) is actually be py -m pip (or py -3 -m pip
if both Python 2 and 3 are installed) rather than simply calling pip.
Adding the scripts directory to the system PATH would mean that pip
works reliably in the "only one Python installation" case, with
py -m pip needed only for the parallel installation case.
Technically, for the 'the user only selected the "put Python on PATH" option for one installation" case.... And if the user selected it more than once, they are already in the land of confusing which-comes-first PATH ordering fun, so working out which pip gets run won't be much extra pain :-)
I think it's also still an open question as to whether getpip should be run in --user mode by default (or as an option) as part of the installation process. There are issues around PATH with doing so, as well as possible confusion because pip does not default to --user. I suspect that the probably answer here should be "--user installs are too immature at the moment to have as the default, but we should look at this again later".
But these minor points aside, I'm +1 on this.
Paul