Virtualenv: library isolated for Python

Windows: cannot create virtualenv on different drive from system Python executable

Reported by Carl Meyer on 2009-04-01
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Virtualenv
New
Undecided
Unassigned

Bug Description

I'm not a Windows user, so I could be missing something, but this is what I'm seeing (ran into it trying to get the pip test suite running on Windows):

S:\>virtualenv --no-site-packages blah
New python executable in blah\Scripts\python.exe
ERROR: The executable blah\Scripts\python.exe is not functioning
ERROR: It thinks sys.prefix is 'c:\\python25' (should be 's:\\blah')
ERROR: virtualenv is not compatible with this system or executable

S:\>c:

C:\>virtualenv --no-site-packages yo
New python executable in yo\Scripts\python.exe
Installing setuptools..............done.

Stefano Masini (stefano-masini) wrote :

I had the same problem.
I fixed it by reinstalling Python2.6. The difference is that the first time (when virtualenv didn't work) I had installed it with the option "Only for this user", while the next time (when it worked) I reinstalled Python with the option "For all users".

Ian Bicking (ianb) wrote :

I've put in an extra error message on Windows when this occurs, suggesting that the user install Python for all users, and pointing them at this bug.

Robert Myers (rmyers) wrote :

The problem is that the pythonXX.dll is missing when you install for 'only this user'. Copying the correct dll into the virtual env scripts folder fixes this issue.

Anywhere before the test "[py_executable, '-c', 'import sys; print sys.prefix']" place the lines:

# Fix python on windows if installed for 'only this user'
    if sys.platform == 'win32':
        # Windows 'may' be installed for 'Only this user' so lets fix it and try again.
        python_dll = os.path.join(os.path.dirname(sys.executable),
            'python%s%s.dll' % (sys.version_info[0], sys.version_info[1]))
        if os.path.isfile(python_dll):
            shutil.copyfile(python_dll, os.path.join(os.path.dirname(py_executable),
                'python%s%s.dll' % (sys.version_info[0], sys.version_info[1])))

Torsten Knodt (torsknod) wrote :

I have a Python 2.5.1 installation made by a Windows software into C:\Program Files\Common Files\...\Python25. The python25.dll is in C:\WINNT\SYSTEM32 so I guess it's a installation for "All users" but virtualenv bails out with the error messages described in this bug.

Any suggestions?

Thanks in Advance
     Torsten Knodt

adesanto (adesantoasman) wrote :

i simply, copied the python2x.dll into C:\windows.

Evaristo (varikvi) wrote :

Adesanto is right - a possible solution is copying python2x.dll into c:\windows

However I am not expert programmer so I am not aware of portability or any other issue/effect when doing so (I think it would be useful to know?)

I think ideally Rober Myers' solution should be a better programming solution?

Evaristo

Wietse (wietse-j) wrote :

I've run into the same problem. I copied over the include directory and the Lib\encodings directory, overwriting the "shortcuts" and than re-ran the command. Now it seems to work.

In virtualenv.py line 409 "symlink" gets a default of "True". It gets called without passing False on Windows.
I changed the virtualenv.py file as follows:

Added line 53:
can_symlink = not is_win

probably more cases need to be added? I'm thinking of cygwin for example...

Changed line 410 from:
def copyfile(src, dest, symlink=True):
into:
def copyfile(src, dest, symlink=can_symlink):

It now works for a new virtual environment.

Carl Meyer (carljm) wrote :

Please use the bugtracker at https://github.com/pypa/virtualenv/issues - this tracker has been unused for years. Unfortunately Ian wasn't able to figure out any way to shut it down.

I see that this has already been solved, sorry for the noise.
https://github.com/nholley/virtualenv/commit/5be60fabcb5d8efb7d05133984b929b3a4b61ea5

Wietse

On 6 January 2012 17:26, Carl Meyer <email address hidden> wrote:

> Please use the bugtracker at https://github.com/pypa/virtualenv/issues -
> this tracker has been unused for years. Unfortunately Ian wasn't able to
> figure out any way to shut it down.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/352844
>
> Title:
> Windows: cannot create virtualenv on different drive from system
> Python executable
>
> Status in Virtualenv: library isolated for Python:
> New
>
> Bug description:
> I'm not a Windows user, so I could be missing something, but this is
> what I'm seeing (ran into it trying to get the pip test suite running
> on Windows):
>
> S:\>virtualenv --no-site-packages blah
> New python executable in blah\Scripts\python.exe
> ERROR: The executable blah\Scripts\python.exe is not functioning
> ERROR: It thinks sys.prefix is 'c:\\python25' (should be 's:\\blah')
> ERROR: virtualenv is not compatible with this system or executable
>
> S:\>c:
>
> C:\>virtualenv --no-site-packages yo
> New python executable in yo\Scripts\python.exe
> Installing setuptools..............done.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/virtualenv/+bug/352844/+subscriptions
>

--
--Wietse

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers