General summary so far
This debate has been very civil so far and quite productive, so thanks
to everyone involved.
Several issues and solution proposals have been mentioned, so I will
make a summary here.
Issue 1: running Python is a different command different OS when several
versions are installed
============================== ============================== ========
Suffix Python executable on Windows like on Unix, so that people will
type pythonX.X if they want a specify version.
Pros: easy and discoverable.
Cons: you need a lot of stuff in the system path.
Provide the "py" command on Unix, so that people will type "py -x.x"
Pros: no more issues with system path. Just add this command, and
register python installations to be listed by "py".
Cons: very few people know about "py", even on windows. This would need
lots of communication. Harder to change Mac and majors Linux distros
setup than just the next windows installer.
Issue 2: there is no one and only one obvious way to do venv / pip
Because pip and venv are tied to a Python version, there are numerous
ways to call them.
Just for pip, you have "pip", "py -x.x -m pip", "pythonx.x -m pip" and
Decide on one form, and promote it everywhere.
Cons: long and tedious process, with a huge inertia before all 3rd party
to it. Would need a "PEP 8 for Python command". Requires "issue 1" to be
Provide a pipenv-like behavior
pipenv is a tool created by the author of "requests" that automatically
"do the right thing" by default. The first time you install a package,
it creates a virtualenv for the current directory (but don't store it in
the current directory). It will then install all packages in there.
"pipenv shell" starts a shell in the virtualenv. Dependencies are
automatically dumped in a requirement files separating dev and prod.
Pros: bypass the multiple installers issue by prompting you what version
you wish the first time it creates a virtualenv. Solve the problem of
admin rights and system path.
Cons: lots of work. Either a new tool or breaking compat with pip. If
debian didn't install pip by default, this may not help.
Issue 3: pip and virtualenv are not available everywhere
Make pip and venv part of the standard and request debian that they
Pros: straight forward.
Cons: holy war in the making.
Favorite personnal combination
1 - So far, I like "providing py on unix" better, but I think it's too
hard to do. So provide suffix on windows seems more achievable.
So +1 for having pythonX.X on windows.
2 - Decide on one form, and promote it everywhere is again the simplest
IMO. I love pipenv but the strings to pull to get something like this
means it probably would not happen.
If we stick to suffix for issue 1, this mean we can promote:
pythonX.X -m pip
pythonX.X -m venv
Everywhere. In the docs. In the tutorials. In teaching classes.
This will help a lot to remove all confusions and make the Python start
up experience way easier.
3 - getting angry debian devs is probably not wise. The "mock" pip/venv
command also plays very well with the 2 other solutions.
It means we can promote everywhere:
pythonX.X -m cmd
It will work most of the time.