Use python -m to create virtualenvs #1316
Conversation
Fixes readthedocsgh-1263, failure to create Python 3 virtualenvs (I hope) The problem appears to be that `virtualenv -p python3` re-executes its own file in site-packages as a script under Python 3. Because the directory containing a script is prepended to `sys.path`, the contents of Python 2 site-packages are then on sys.path for Python 3. [python- future](http://python-future.org/) is installed in Python 2, providing certain standard library modules under their Python 3 names. So when it tries to import copyreg, it finds the compatibility module for Python 2 instead of the standard Python 3 module, making future fail with the error: ImportError: This package should not be accessible on Python 3. Either you are trying to run from the python-future src folder or your installation of python-future is corrupted. As suggested by @dstufft, this invokes `python3 -m virtualenv` instead, which will cause Python 3 to run its own copy of virtualenv, and should avoid this issue. This requires virtualenv to be installed in Python 3 as well; I don't know if it already is, but it should be easy to arrange if not.
|
I'm not exactly sure how the failures could be transient, as some people report, but if there are multiple builders and not all of them have |
|
Looks sane. Let's see if it fixes the build issues we've been seeing. |
Use python -m to create virtualenvs
|
Looks like it's fixed for me. I checked and nothing had python-future installed. I couldn't make heads or tails of the randomness of the errors, but it seems this did it. |
|
I possibly bumped onto the same issue today. |
|
That's a new issue - the cause is unrelated, but the symptom is similar. See #1350 and sphinx-doc/alabaster#40. It's actually already fixed, but it needs a new release of alabaster now. Or RTD could make a temporary workaround. @bitprophet, is there an ETA on alabaster 0.7.6? |
|
Should be up just now, @takluyver. |
|
Thanks! :-)
|
Fixes gh-1263, failure to create Python 3 virtualenvs (I hope)
The problem appears to be that
virtualenv -p python3re-executes its own file in site-packages as a script under Python 3. Because the directory containing a script is prepended tosys.path, the contents of Python 2 site-packages are then on sys.path for Python 3. python-future is installed in Python 2, providing certain standard library modules under their Python 3 names. So when it tries to import copyreg, it finds the compatibility module for Python 2 instead of the standard Python 3 module, making future fail with the error:ImportError: This package should not be accessible on Python 3. Either you are trying to run from the python-future src folder or your installation of python-future is corrupted.
As suggested by @dstufft, this invokes
python3 -m virtualenvinstead, which will cause Python 3 to run its own copy of virtualenv, and should avoid this issue. This requires virtualenv to be installed in Python 3 as well; I don't know if it already is, but it should be easy to arrange if not.