On 10 November 2017 at 10:01, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 10 November 2017 at 19:50, Paul Moore <p.f.moore@gmail.com> wrote:
On 10 November 2017 at 08:01, Nick Coghlan <ncoghlan@gmail.com> wrote:
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.
We already assume there will be a step in understanding from "working with the latest Python 3.x locally" to "dealing with multiple Python versions". Switching from venv to virtualenv just becomes part of that process (and will often be hidden behind a higher level tool like pipenv, pew, or vex anyway).
OK, that's fair. Paul