[Eric] install.py does not seem to respect virtual environments

Boylan, Ross Ross.Boylan at ucsf.edu
Sat Dec 7 21:05:34 GMT 2019


Having stepped through the code and examined the documents, it seems to me the documentation has some unresolved contradictions about what rules apply in this case, but that either set that could apply mean py install.py should invoke the venv's Python 3.7. Which is not what happens. This seems like more of a Python issue than an eric issue, though it's possible eric could work around it by, e.g., changing the #! line at the start of install.py.*

Context: invoking "py installer.py" from within a 3.7 virtual environment on Win10.  The first line of installer.py is
#!/usr/bin/env python3

sys.exec_prefix (e.g., line 184 of initGlobals()) points at my user-specific 3.8 installation.  base_exec_prefix and executable do as well.
The documentation for sys says that exec_prefix should point to a virtual environment if it is invoked in that context, so this seems like an error.

However, the documentation for the py launcher in the Windows section of "Python Setup and Useage" says 2 things:
Section 3.7.1.2 says if py is invoked from a virtual environment with no explicit version specified, it will run the virtual environment's interpreter.
The behavior is inconsistent with that.

But Section 3.7.2 discusses scripts and #! lines and it is not clear if one invokes a script from a virtual environment whether 3.7.1.2 or 3.7.2 is supposed to apply.  Supposing the latter, the relevant part says that if the /usr/bin/env form is used the executable PATH will be searched.  However, because I am in an active virtual environment, the first entry in my PATH points to the venv's Scripts directory, which again should get me the venv Python 3.7, not the non-virtual 3.8.

So whether 3.7.1.2 or 3.7.2 governs, the documents seem to say I should get my venv python interpreter, but I don't.  Or at least, sys.exec_prefix and friends aren't set consistent with that.

There are a couple of wrinkles.  If py doesn't inherit the PATH from my terminal session, getting my default PATH instead, it will get a PATH that only has Python 3.8 on it (because of the options I selected on installation of Python 3.7 and 3.8).  So that could result in getting the "wrong" python.  Also, I recall seeing some caution/bug that user settings in PATH were processed after system settings.  Even if true, I'm not sure how it's relevant, but if my venv path is processed after the python 3.8 path the /usr/bin/env interpretation by py would pick 3.8.

*I replaced the #! line with a blank line and got the venv python for sys.exec_prefix.  So I think that's enough to fix this problem, though admittedly it might cause other problems :(


More information about the Eric mailing list