On 19 August 2013 15:28, Nick Coghlan <ncogh...@gmail.com> wrote: > > 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: >
Thanks for the update, Nick. I'll wait for Donald's comments and the published version of the PEP before commenting in detail, but the following points come to mind for me at least: 1. I would still like to see *some* clear statement of what the "guaranteed interface" users can rely on is. Maybe I'm suggesting more than anyone else is willing to commit to, but I *do* think that if we're suggesting that there is now a "standard Python installer", we should give users some indication of what it actually is. For example, I think it's reasonable as a user to assume that "pip install foo" will work for the foreseeable future - but not that (for example) "pip bundle" will. 2. We need to be careful to define exactly when and how the "pip" command is present. Don't forget that on Windows, the "python" command is not on PATH by default (and the existence of the launcher means that it really doesn't need to be). I would suggest that we say something like "The pip command will be installed alongside the python command, and will be available when python is"[1]. We should also probably note that versioned variants of pip will be provided matching the versioned copies of the python command that are available (e.g., pip3/pip3.4 on Unix, maybe none at all on Windows...). Unless of course we want to use a different scheme for pip, in which case we need to agree on what that will be. 3. This also begs the question of whether pip.exe gets installed in the "Scripts" subdirectory on Windows, as at present - if it does, we'll have to be very careful indeed over how we word the instructions, as it's *easy* for users to have python.exe on PATH but not have Scripts\pip.exe on there :-( Paul. [1] I don't like that wording, but I can't find a better way of putting it that covers all cases but isn't too wordy :-(
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
