[Python-ideas] Looking for input to help with the pip situation

Steve Dower steve.dower at python.org
Wed Nov 15 14:07:31 EST 2017

On 15Nov2017 0617, Nick Coghlan wrote:
> On 15 November 2017 at 22:46, Michel Desmoulin 
> <desmoulinmichel at gmail.com <mailto:desmoulinmichel at gmail.com>> wrote:
>     Should I do a PEP with a summary of all the stuff we discussed ?
> I think a Windows-specific PEP covering adding PATH updates back to the 
> default installer behaviour, and adding pythonX and pythonX.Y commands 
> would be useful (and Guido would presumably delegate resolving that to 
> Steve Dower as the Windows installer maintainer).

If you write such a PEP, please also research and write up the issues 
with modifying PATH on Windows (they're largely scattered throughout 
bugs.p.o and earlier discussions on python-dev).

Once you realise the tradeoff involved in modifying these global 
settings, you'll either come around to my point of view or be 
volunteering to take *all* the support questions when they come in :)

> The one thing I'd ask is that any such PEP *not* advocate for promoting 
> ther variants as the preferred way of invoking Python on Windows - 
> rather, they should be positioned as a way of making online instructions 
> written for Linux more likely to "just work" for folks on Windows 
> (similar to the utf-8 encoding changes in 
> https://www.python.org/dev/peps/pep-0529/)
> Instead, the focus should be on ensuring the "python -m pip install" and 
> "pip install" both work after clicking through the installer without 
> changing any settings, and devising a troubleshooting guide to help 
> folks that are familiar with computers and Python, but perhaps not with 
> Windows, guide folks to a properly working environment.

My preferred solution for this is to rename "py.exe" to "python.exe" (or 
rather, make a copy of it with the new name), and extend (or more 
likely, rewrite) the launcher such that:

* if argv[0] == "py.exe", use PEP 514 company/tag resolution to find and 
launch Python based on first command line argument
* if argv[0] == "python<numeric tag>.exe", find the matching 
PythonCore/<tag> install (where tag may be a partial match - e.g. 
"python3.exe" finds the latest PythonCore/3.x)
* else, if argv[0] == "<module><numeric tag>.exe, find the matching 
PythonCore/<tag> install and launch "-m <module>"

With the launcher behaving like this, we can make as many hard links as 
we want in its install directory (it only gets installed once, so only 
needs one PATH entry, and this is C:\Windows for admin installs):
* python.exe
* python2.exe
* python3.exe
* python3.6.exe
* pip.exe
* pip2.exe
* pip3.exe

As well as allowing e.g. "py.exe -anaconda36-64 ..." to reliably locate 
and run non-Python.org installs.

It needs to be fully specced out, obviously, and we may want to move the 
all-users install to its own directory to reduce clutter, but part of 
the reason behind PEP 514 was to enable this sort of launcher. It could 
even extend to "you don't have this version right now, want to download 
and install it?"

And finally it should be fairly obvious that this doesn't have to be a 
core Python tool. It has no reliance on anything in core (that isn't 
already specified in a PEP) and could be written totally independently. 
I've tried (weakly) to get work time allocated to this in the past, and 
if it's genuinely not going to get done unless I do it then I'll try again.


More information about the Python-ideas mailing list