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 :(
_______________________________________________
Eric mailing list
[email protected]
https://www.riverbankcomputing.com/mailman/listinfo/eric

Reply via email to