On 15Nov2017 0617, Nick Coghlan wrote:
On 15 November 2017 at 22:46, Michel Desmoulin
<desmoulinmic...@gmail.com <mailto:desmoulinmic...@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.
Cheers,
Steve
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
