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