<p dir="ltr"><br>
On 6 Sep 2014 23:15, "Paul Moore" <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br>
><br>
> On 6 September 2014 13:47, Skip Montanaro <<a href="mailto:skip@pobox.com">skip@pobox.com</a>> wrote:<br>
> > Based on the comment in the second issue, it doesn't appear this will<br>
> > be resolved until 1.7 at the earliest.<br>
><br>
> The second issue is specific to setuptools, where we have some very<br>
> unpleasant hacks to deal with the setuptools/distribute mess.<br>
><br>
> Having said that I don't have an immediate feel for what proportion of<br>
> the issues around --user are fixed in 1.6, as I don't personally use<br>
> --user much.</p>
<p dir="ltr">Using virtual environments also avoids some bad interactions between pkg_resources.requires() and the way Fedora (et al) handle parallel installation of mutually incompatible versions of components that use the same module namespace (e.g. CherryPy 2 vs CherryPy 3) into the system Python.</p>
<p dir="ltr">The specific reason for the assumption of virtual environment usage on POSIX is slightly different though: inside a virtual environment created with pyvenv, "python" always refers to Python 3, regardless of platform.</p>
<p dir="ltr">Thus, the assumption let me avoid a long-winded explanation of PEP 394 and why the system-wide "python" refers to Python 2 and you need to run "python3 -m pip" to install into Python 3 instead. It was the system level pip vs pip3 distinction that prompted the original change to recommending "-m pip", and I realised explaining the vagaries of python vs python3 would be just as distracting & uninteresting for most users.</p>
<p dir="ltr">There's a question at the end of the document about installing into the system Python that could probably be expanded on with more details, but there really are enough ugly edge cases to running custom code in the system Python (at least currently) that the simplest answer is "don't". </p>
<p dir="ltr">Cheers,<br>
Nick.</p>