On Tue, 14 Nov 2017 12:14:50 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
I don't think Windows ever had python2.exe/python3.exe, but I could be wrong.
Not that I'm aware of in the python.org installers, and I don't think ActivePython does either. I'm less sure about Enthought or Anaconda (since I've never used either of them on Windows).
Looking at my Windows VM... * from a Miniconda install (equivalent, I think, to a bare-bones Anaconda with the minimal package set required for a function "python" and "conda"): c:\>where python C:\Miniconda3\python.exe c:\>where python3 INFO: Could not find files for the given pattern(s). * from a user-created conda environment: c:\>activate da36 (da36) c:\>where python C:\Miniconda3\envs\da36\python.exe C:\Miniconda3\python.exe (da36) c:\>where python3 INFO: Could not find files for the given pattern(s). (no clue about Enthought, sorry)
Yeah, myself, Barry Warsaw, Matthias Klose, and a number of other folks on linux-sig have poked at this idea multiple times since Geoff Thomas first posted about https://github.com/geofft/pythonmux, but our conclusion each time has been that it wouldn't help enough to justify the effort involved in implementing and promoting it. After 20+ years of usage in the Linux ecosystem, `/usr/bin/python` and `/usr/bin/env python` are simply too entrenched in both people's habits and existing code.
+1. As a matter of fact, Anaconda also doesn't seem to expose "py" on Windows: (da36) c:\>py 'py' is not recognized as an internal or external command, operable program or batch file.
3) Make --user be be automatic for pip install. Not actually the default, but pip could do a user install if you don't have the permissions for a non-user install.
The problem here is that the user scripts directory isn't on PATH. We could put it on, but again we hit the "goes after the system PATH" problem (on Windows).
We should still optimise the defaults for the desired system configuration (i.e. user-mode installs as the cross-platform default outside a venv), and then work on platform-specific troubleshooting guides for the common ways that things can go wrong.
Hmm... I liked --user at some point, but if you start using it a lot it becomes problematic, for example if you want to install two different scripts/applications with incompatible dependencies. That said, it *is* much better than system-wide installs of user packages :-) Regards Antoine.