New issue
Advanced search Search tips

Issue 877620 link

Starred by 0 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

vpython isn't able to run CIPD-distributed python on Windows

Project Member Reported by tandrii@chromium.org, Aug 24

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  


 
So I figured out the problem: for some reason, depot_tools\.cipd_bin\vpython.exe was running the python included in my emacs install. I had my emacs\bin included on my path, but it was after everything else (the depot_tools python, the pre-installed python, etc). Removing emacs from my path solved the problem.

However, it does seem strange that this would happen, given emacs was at the end of the path. I can provide more information if necessary; I have a Process Monitor dump of the relevant processes.
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?
Cc: collinbaker@chromium.org
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.

Sure thing; I'll give the output by the end of the day.
Owner: collinbaker@chromium.org
Status: Assigned (was: Untriaged)
Owner: ----
Status: Available (was: Assigned)
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
Cc: iannu...@google.com
Cc: -iannucci@chromium.org
Cc: mfo...@chromium.org
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?
Labels: Pri-2
Setting defect without priority to Pri-2.

Sign in to add a comment