Issue metadata
Sign in to add a comment
|
vpython isn't able to run CIPD-distributed python on Windows |
||||||||||||||||||||
Issue description
This is on a new machine but it was working a few days ago.
The errors look like this:
New python executable in C:\Users\collinbaker\.vpython-root\5396bd\Scripts\python2.7.exe
Also creating executable in C:\Users\collinbaker\.vpython-root\5396bd\Scripts\python.exe
ERROR: The executable C:\Users\collinbaker\.vpython-root\5396bd\Scripts\python2.7.exe is not functioning
ERROR: It thinks sys.prefix is u'c:\\src\\temp\\vpython_bootstrap775135254\\packages\\virtualenv-15.1.0' (should be u'c:\\users\\collinbaker\\.vpython-root\\5396bd')
ERROR: virtualenv is not compatible with this system or executable
,
Aug 24
hm... that does sound like vpython has a bug in its path lookup behavior. could you run with the argument `-vpython-log-level debug` too (and attach the output) so we can see what vpython thinks is going on?
,
Aug 27
From an email: This looks like a VirtualEnv setup error. Please try running VirtualEnv directly via (doing this on phone so pardon any errors): pip install -u VirtualEnv python -m VirtualEnv This should set up a VirtualEnv, and if all's consistent it will also fail similarly. Another thing to try is to run vpython directly with debug output. The binary is in your depot_tools directory: vpython -vpython-log-level debug Collin - can you recreate the bug, try these steps, and share the results? It would be good to know whether they give any extra information and whether they work as diagnostic techniques in this particular case. If they work then it would be nice to have them printed somewhere when this failure is detected - I assume that *somebody* will hit this again.
,
Aug 27
Sure thing; I'll give the output by the end of the day.
,
Aug 30
,
Aug 30
Sorry, I forgot. Here's the invocation that works: https://paste.googleplex.com/5407916957892608 Here's the one that doesn't: https://paste.googleplex.com/4979318413328384 `where python` gives: > C:\src\depot_tools\python.bat > C:\python_27_amd64\files\python.exe > C:\src\emacs\bin\python.exe C:\src\chromium2\src\ is checked out @ 0d639a0e5070a8b8ad6feb019728826e6d641b7f C:\src\depot_tools\ is checked out @ cb32668137d08ec52ee893a872df3a61903215a2
,
Oct 18
,
Oct 18
,
Nov 15
I also hit this. I have Emacs for Windows installed. However `where python` gives: C:\python_27_amd64\files\python.exe C:\src\depot_tools\python.bat C:\src\emacs\bin\python.exe Removing C:\src\emacs\bin from my %Path% fixed it. Should gclient just prune any python-s from the %Path% that are not compatible?
,
Jan 11
Setting defect without priority to Pri-2. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by collinbaker@chromium.org
, Aug 24