New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using virtualenv with --python and a 32 bit Python breaks on Windows #774

Open
The-Compiler opened this Issue Jun 23, 2015 · 2 comments

Comments

Projects
None yet
2 participants
@The-Compiler

The-Compiler commented Jun 23, 2015

When trying to use virtualenv started with a 64bit python and passing --python=/path/to/32bit/python, this breaks on Windows:

C:\Users\florian\tmp>C:\Python34\python.exe -m virtualenv --python=C:\Python34_x32\python.exe venv3
Running virtualenv with interpreter C:\Python34_x32\python.exe
Fatal Python error: Failed to initialize Windows random API (CryptoGen)

I investigated a bit and it seems this happens when using subprocess with env=... to start python in general - I opened Issue 24493 in Python's tracker because of that.

However I think virtualenv should work around this issue if possible. What do you think about not using env= and not setting VIRTUALENV_INTERPRETER_RUNNING, and instead adding a hidden argument which is passed when re-executing?

I also thought about removing the --python argument from the commandline, but that seems brittle, as e.g. --python=... or --python ... or -p ... could be passed.

If that sounds like an acceptable workaround, I can open a PR with the change.

Ivoz added a commit to Ivoz/virtualenv that referenced this issue Oct 2, 2015

Remove file's directory from sys.path ASAP
This is needed to particularly when a new interpreter is used,
via -p/--python. Re-execing the same `virtualenv.py` will generally lead
to its path being added to the start of sys.path (as usual). And usually
its path will be the site-packages of the previous interpreter. This
will lead to issues if older backported packages are present in the
old environment (which will then get preference being imported).

Should fix pypa#779, pypa#774, pypa#763
@Ivoz

This comment has been minimized.

Member

Ivoz commented Oct 2, 2015

@The-Compiler would appreciate if you could check if the above commit solves the issue

https://github.com/Ivoz/virtualenv/archive/early-syspath-removal.zip

@The-Compiler

This comment has been minimized.

The-Compiler commented Oct 2, 2015

It doesn't, unfortunately.

Ivoz added a commit to Ivoz/virtualenv that referenced this issue Oct 2, 2015

Remove file's directory from sys.path ASAP
This is needed to particularly when a new interpreter is used,
via -p/--python. Re-execing the same `virtualenv.py` will generally lead
to its path being added to the start of sys.path (as usual). And usually
its path will be the site-packages of the previous interpreter. This
will lead to issues if older backported packages are present in the
old environment (which will then get preference being imported).

Should fix pypa#779, pypa#774, pypa#763

Ivoz added a commit to Ivoz/virtualenv that referenced this issue Oct 17, 2015

Remove file's directory from sys.path ASAP
This is needed particularly when a new interpreter is used,
via -p/--python. Re-execing the same `virtualenv.py` will generally lead
to its path being added to the start of sys.path (as usual). And usually
its path will be the site-packages of the previous interpreter. This
will lead to issues if older backported packages are present in the
old environment (which will then get preference being imported).

Should fix pypa#779, pypa#774, pypa#763
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment