On 10 November 2017 at 10:01, Nick Coghlan <ncogh...@gmail.com> wrote: > On 10 November 2017 at 19:50, Paul Moore <p.f.mo...@gmail.com> wrote: >> On 10 November 2017 at 08:01, Nick Coghlan <ncogh...@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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
