Giters

sashahart / vex

Run a command in the named virtualenv.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Windows: cannot create venv: executable does not exist

schlamar opened this issue · comments

commented

I'm getting the following error on Windows (in msysgit's bash and on cmd):

$ vex -mr --python=python myvenv
The executable python (from --python=python) does not exist
Error: error creating virtualenv

$ which python
/c/Python27/python
commented

Thanks for this report on how vex works on Windows, these are essential to being able to support Windows at all.

This message is coming from virtualenv itself (I recognize it, vex -m is just a thin wrapper for running virtualenv and 'The executable' does not occur anywhere in vex's own code).
So I would be surprised if you didn't see the same problem directly running 'virtualenv myvenv --python=python'. Let me know if you could.

I have always just used full paths to the python interpreter when running virtualenv on windows just to avoid this nonsense. Possibly virtualenv just isn't ever searching %PATH%. However, typically this isn't virtualenv's fault because the interpreter is not on %PATH% anyway, and there is no sensible way to just guess where it might be in the filesystem, or in fact which python the user actually means, unless they put it on %PATH%; at the same time, appending to %PATH% is an overcomplicated PITA on Windows and most users won't do it; at the same time, it's arguably not even a good idea because of the potential for multiple things to depend on different meanings for 'python' - a problem typically solved by virtualenv, thus there's no particularly nice way to solve it when invoking virtualenv itself. So typically on Windows you supply a full path yourself to bootstrap the process. I know, blah.

Do you have C:\Python27 included in %PATH% ? Unfortunately, right now I don't have a windows machine to hand to replicate, I have to rent an EC2 instance and use it over RDP which is painful and time-consuming.

commented

Oh yeah, if you want to help track windows bugs down it will be nicest to do it on CMD.EXE or PowerShell first. I do want things to work under msysgit's bash in the longer term, but it's more obscure and I first want to know that I am dealing with the more typical Windows behavior before I (possibly) get far into weirdnesses specific to msysgit bash.

commented

virtualenv myvenv --python=python fails, too. However virtualenv myvenv works so maybe you should omit passing this argument to virtualenv if it's not specified.

commented

Upstream bug report: pypa/virtualenv#640

commented

Thanks very much for checking this and making the bug report. My request about cmd was driven by your example being presented using a Unix-style shell (I assumed cygwin).

If the actual usability issue here is not addressed in virtualenv in a reasonably timely way, then I may address it in vex by successfully switching away from the virtualenv executable in favor of importing and reusing some of its implementation. The problem will be if there is an underlying reason why virtualenv can't find python; in the face of uncertainty I'm not willing to start guessing paths to check.

commented

for now I'm working around this in normal windows with distutils, but that may be removed in the future.

There is no way any environment pretending to act like shell should need this worked around downstream of virtualenv