> 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. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
