On 14 November 2017 at 16:47, Michel Desmoulin firstname.lastname@example.org wrote:
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
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.
Con: we hope to have the problem resolved on the Linux distro side such that "python" typically means "python" by the time community support for Python 2 ends in 2020. Since Windows has gone the better part of two decades without version Python commands, adding them because we're impatient with the pace of change at the Linux distro level doesn't really make sense (especially when Linux holds such a small fraction of the non-phone client device market).
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.
Make sure 'python' just works on a default Window user install, and treat any system where that doesn't work by default as a special case that needs troubleshooting.
Pro: a solid troubleshooting guide will be useful regardless
Con: mainstream Linux distros will still be a consistent exception for at least the next couple of years (and probably longer for the LTS variants)
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 "pipx".
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 solved before.
This downside doesn't apply as long as the form we standardise on is "pip install module".
That already works in a lot of contexts, and the cases where it doesn't work are typically ones where "python -m pip" may also be a problem.
Given a solid troubleshooting guide for issue 1, we may also be able to add some implicit checks to pip that provide alerts for problematic configurations, like checking:
>>> user_scheme = "posix_user" # or "nt_user" or "osx_framework_user" >>> sysconfig.get_path("scripts", scheme="posix_user") in
The latter check returning false is a sign that the
might be a problem.
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.
This is essentially the path that conda takes, and it works well for folks that are willing to adopt conda's specific approach to managing your Python runtimes.
Make pip and venv part of the standard and request debian that they provide it.
Pros: straight forward.
Cons: holy war in the making.
I don't think it's that bad. Debian does have support for weak dependencies, so the resolution here may be as simple as asking Matthias to add a Recommends from python3 to python3-venv so that ensurepip is present by default on typical workstation configurations, but can still be easily omitted from server configurations.
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.
I think this is actually similar to the situation with 'py' on *nix systems: with Windows having never had these before, adding and promoting them would be at best ineffective, and at worst outright confusing (especially if "python" starts meaning Python 3 by default on Linux as well within the next few years).
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.
We've been evaluating a potential pipenv tutorial for the Python Packaging User Guide, and while we're likely going to add it soon, it will be as a new "application dependency management" tutorial alongside the existing ones, rather than as a direct replacement for the pip-based "package installation" tutorial: https://github.com/pypa/python-packaging-user-guide/issues/394#issuecomment-...
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.
Except it won't, because now you can't seamlessly update your class instructions to new versions of Python - you'll have to go through and change all the "X.Y" references to refer to the right version. Writing cross-platform scripts will also get even harder, as you wouldn't be able to say "I just need a version of Python, I don't really care which one" any more.
Python feature releases are already disruptive enough due to filesystem layout changes and file format changes - we don't need to make them worse by encouraging people to embed the exact target version in their documentation and helper scripts.
3 - getting angry debian devs is probably not wise. The "mock" pip/venv command also plays very well with the 2 other solutions.
While I was a bit snarky about "python -m venv" being broken by default
earlier in the thread, please don't take that as meaning that we can't
collaborate constructively with the Debian folks. We can, and do, but the
friction between language level package management and system level package
management is one with a long history that we're all working towards
resolving together (See  &  for write-ups of a couple of linux.conf.au
talks I've given about the problem), as is the question of how best to
It means we can promote everywhere:
pythonX.X -m cmd
It will work most of the time.
The combination of:
pip install package python -m venv
already works in most cases, except apparently the critical one of "New Python user on Windows downloads the python.org installer and clicks through all the buttons without changing any settings".
So I think the main near term step forward would be to convince Steve Dower (as the Windows installer maintainer) to change that default behaviour yet again for 3.7, and then work towards coming up with a solid environment troubleshooting guide to include on packaging.python.org.
-- Nick Coghlan | email@example.com | Brisbane, Australia