[Python-ideas] Looking for input to help with the pip situation

[Michel Desmoulin]

> 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 user environment if it didn't already exist
>> * launched a subshell with that environment already activated
>>
>> This wouldn't be a full environment manager like vex or pew - it would
>> just be a way to bootstrap a single usable package management
>> environment in a cross-platform way.
> 
> "How do I run venv?" is no easier to answer in a cross-platform way
> than "how do I run pip?" You still need to be able to run
> python/python3/py. About the only improvement is that there's no
> legacy of documentation and advice on the web saying "run venv" like
> there is for "run pip"...
> 
> Paul
>

Exactly.