> On Windows, which is the only platform I can reasonably comment on,
> the killer issue is that the installer doesn't make the commands
> "python" and "pip" available by default. Just checking my PC, both go
> and rust (which I installed *ages* ago) do appear to, so they "just
> work". Java sort-of also works like that (the runtime is on PATH, but
> the compilers need to be added manually).
>
> The biggest reason we don't add Python to PATH, as I understand it, is
> because we need to consider the implications of people having multiple
> versions of Python installed. As far as I know, no other language
> allows that. But equally, most beginners wouldn't actually *have*
> multiple versions installed. So maybe we should optimise for that case
> (only one version of Python installed). That would mean:
>
That seems reasonable. Especially since somebody with several versions
install is more likely to know how to deal with system path issues than
a total beginner installing python for the first time.
> 1. Go back to adding Python to PATH. Because our installers don't say
> "do you want to uninstall the old version", we should probably do a
> check for a "python" command on PATH in the installer, and if there is
> one, warn the user "You already have Python installed - if you are
> upgrading you should manually uninstall the old version first,
> otherwise your old installation will remain the default". We could get
> more complex at this point, but that depends on what capabilities we
> can include in the installer - I don't know how powerful the toolset
> is.
You don't even have to do that. We can detect it and prompt : "which
python version do you want to be available by default ?", and then list
command to run the alternative versions.
> 2. Explicitly document that multiple Python interpreters on one
> machine is considered "advanced", and users with that sort of setup
> should be prepared to manage PATH themselves. I'd put that as
> something like "It is possible to install multiple versions of Python
> at once, but if you do that, you should understand the implications -
> the average user should not need to do this"
>
> We still have to deal with the fact that basically every Unix
> environment is "advanced" in the above sense (the python2/python3
> split). I don't have a solution for that (other than "upgrade to
> Windows" ;-)).
Provide the "py" command on linux and mac. And make it the default
recommended way in the documentation.
>> It doesn't completely solve the problem (as getting into and out of
>> the environment is still platform specific), but it does mean that the
>> ubiquitous online instructions to run "pip install package-name" and
>> "python -m command" will actually work once people are inside their
>> working environment.
>>
>> That tooling is venv:
>>
>> * it ensures you have "pip" on your PATH
>> * it ensures you have "python" on your PATH
>> * it ensures that you have the required permissions to install new packages
>> * it ensures that any commands you install from PyPI will be also on your
>> PATH
>>
>> When we choose not to use venv, then it becomes necessary to ensure
>> each of those things individually for each potential system starting
>> state
>
> Currently, the reality is that people use virtualenv, not venv. All
> higher-level tools I'm aware of wrap virtualenv (to allow Python 2.7
> support). Enhancing the capabilities of venv is fine, but promoting
> venv over virtualenv involves technical challenges across the whole
> toolset, not just documentation/education.
>
> But agreed, once we get people into a virtual environment (of any
> form) the portability issues become significantly reduced. The main
> outstanding issue is managing multiple environments, which could be
> handled by having a special "default" environment that is the only one
> we'd expect beginners to use/need.
Well, not exactly. Do you do python -m venv, or py -x.x -m venv or
pythonx -m venv ? Wait, it's not installed by default on debian.
And then virtualenv have their own issues:
- it's a contextual mode that you need to activate AND be aware of at
all time
- you need to config tooling to use it (IDE, builders, etc)
- the location of virtualenv is very important
- you should not commit it to git
- you can't relocate it easily
- install jupyter / mymy / flake8 outside a virtualenv and the command
will still seems to work inside a virtualenv it's not installed in. With
terrible consequences.
Virtualenvs are a hard tool to use for beginners.
A lot of people on this list have forgotten their early years it seems.
> Also on Windows, the per-user bin directory isn't added to PATH even
> if you add the system Python to PATH in the installer.
>
>> That said, I think there is one improvement we could feasibly make,
>> which would be to introduce the notion of a "default user environment"
>> into `venv`, such that there was a single "python -m venv shell"
>> command that:
>>
>> * created a default
