On 10 November 2017 at 17:05, Michel Desmoulin desmoulinmichel@gmail.com wrote:
Which is why we advise getting into a virtual environment ASAP, such that the only platform specific thing folks necessarily need to learn to get started is how to get to that first working virtual environment.
You can't start by teaching virtualenv. I tried. It doesn't work. And it's a terrible prerequisit if you write docs, tutorial, teaching materials, etc.
You can't have it both ways - the only way we can systematically mask the environmental differences between Windows, Linux and Mac OS X is by providing tooling that actually masks those differences, which means introducing that tooling becomes a prerequisite for teaching.
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
That said, we'd *like* the default to be is per-user package installations into the user home directory, but that creates additional problems:
* "python" may be missing, and you'll have to use "python3" or "py" instead * "pip" may be missing (or mean "install for Python 2.7") * you have to specify "--user" on *every* call to pip, and most online guides won't say that * there's a major backwards compatibility problem with switching pip over to per-user package installs as the default (we still want to do it eventually, though) * on Windows, system-wide Python installs can't adjust per-user PATH settings, and per-user installs are subject to being broken by system-wide installs * on Windows, the distinction between a per-user install of Python, and per-user installs of a package is hard to teach * on Debian, I believe ~/.local/bin still isn't on PATH by default
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.
Cheers, Nick.