virtualenv-burrito
virtualenv-burrito copied to clipboard
mkvirtualenv fail python3
Installed Python 3 brew install python3
then mkvirtualenv -p /usr/local/bin/python3 testpy3
got this error:
Running virtualenv with interpreter /usr/local/bin/python3
Using base prefix '/usr/local/Cellar/python3/3.3.0/Frameworks/Python.framework/Versions/3.3'
New python executable in testpy3/bin/python3
Also creating executable in testpy3/bin/python
Installing distribute......................................................................................................................................................................................................................................................................................................................................................................................................done.
Installing pip..........
Complete output from command /Users/mam/.virtualenvs/testpy3/bin/python3 -x /Users/mam/.virtuale...py3/bin/easy_install /Users/mam/.venvburr...ort/pip-1.2.1.tar.gz:
Traceback (most recent call last):
File "/Users/mam/.virtualenvs/testpy3/bin/easy_install", line 5, in <module>
from pkg_resources import load_entry_point
File "/Users/mam/.venvburrito/lib/python/distribute-0.6.32-py2.7.egg/pkg_resources.py", line 45
def _bypass_ensure_directory(name, mode=0777):
^
SyntaxError: invalid token
----------------------------------------
...Installing pip...done.
Traceback (most recent call last):
File "/Users/mam/.venvburrito/lib/python/virtualenv-1.8.4-py2.7.egg/virtualenv.py", line 2560, in <module>
main()
File "/Users/mam/.venvburrito/lib/python/virtualenv-1.8.4-py2.7.egg/virtualenv.py", line 964, in main
never_download=options.never_download)
File "/Users/mam/.venvburrito/lib/python/virtualenv-1.8.4-py2.7.egg/virtualenv.py", line 1076, in create_environment
install_pip(py_executable, search_dirs=search_dirs, never_download=never_download)
File "/Users/mam/.venvburrito/lib/python/virtualenv-1.8.4-py2.7.egg/virtualenv.py", line 667, in install_pip
filter_stdout=_filter_setup)
File "/Users/mam/.venvburrito/lib/python/virtualenv-1.8.4-py2.7.egg/virtualenv.py", line 1042, in call_subprocess
% (cmd_desc, proc.returncode))
OSError: Command /Users/mam/.virtualenvs/testpy3/bin/python3 -x /Users/mam/.virtuale...py3/bin/easy_install /Users/mam/.venvburr...ort/pip-1.2.1.tar.gz failed with error code 1
let me know if I can be of further assistance
@brainsik, this is the issue that I mentioned to you a while ago. What's happening is this:
In standard usage, distribute's setup.py
detects if it's being run under Python 3 and, if so, runs the code of distribute through 2to3
before installing it in site-packages
.
This means that the source code for distribute was never intended to run under Python 2 and 3. When virtualenvburrito puts it inside ~/.venvburrito/lib/python/
, that is done with Python 2.x, so it's not run through 2to3
. But virtualenvburrito modifies PYTHONPATH
, which affects both Python 2 and 3, and you end up with Python 3 trying to import the Python 2 version of distribute.
While it may be a questionable choice for distribute to not update their code to work under 2 and 3 (they rejected my pull request to do exactly that: https://bitbucket.org/tarek/distribute/pull-request/7/fixes-for-python-3-compatibility/diff ), ultimately I think this requires a bit of a rethink to how virtualenvburrito installs its dependencies and modifies PYTHONPATH
.
I don't use virtualenv-burrito, but ended up here after a link from a discussion of this on distribute.
Only after Python 3.2 is it possible to share libraries across Python versions, as only then can you have .pyc files for several versions of Python in the same directory. As such, virtualenv-burrito should not modify PYTHONPATH in this way.
I'm also facing this bug (using virtualenv-burrito on debian): mkvirtualenv -p python3 myvenv
will generate the same error as @MichaelMartinez reported.
I'm encountering the same error on OSX with python 3.3. Is there a work around?
Thank you for your help, I'm just getting started with python and I look forward to using it.
Please let me know if I can provide any additional information.
Nope, there is no fix to this yet - it's a structural flaw in virtualenv-burrito
that will take some work to fix. Python 3.3 comes with the venv
package, you might be able to use that instead of virtualenv-burrito
.
Thank you for getting back to me to me. Is there a way to uninstall virtualenv-burrito since I can't use it?
Thank you again for for your help.
To uninstall:
- Remove the section that it added to your
~/.profile
file, mine looks like this:
# if running bash
if [ -n "$BASH_VERSION" ]; then
# startup virtualenv-burrito
if [ -f "$HOME/.venvburrito/startup.sh" ]; then
. "$HOME/.venvburrito/startup.sh"
fi
fi
- Remove your
~/.venvburrito/
directory
Got it! Thanks again.
I've run into this same issue. Would a pull request fix be considered?
A pull request would be welcome, but it's pretty complicated to fix. Rather than having one set of libraries under ~/.venvburrito/
and a modified PYTHONPATH
, what is needed is a separate set of libraries for various Python 2.x versions and Python 3, and some way of detecting the right set based on the desired Python version. I do think it would be ok if a fix targeted just Python 2.6/2.7 and Python 3.3 and up. Very few people are using 3.0/3.1/3.2.
A change I just made for getting this to work with Homebrew's Python is a step in the right direction. Many of the packages used by Virtualenv Burrito are now living in a platform specific directory (e.g., $HOME/.venvburrito/lib/python2.7).
There's still a lot of work left to do to get this issue fixed.
I really hope this gets fixed soon, I stumbled upon this problem right now. So lots of love and encouragement for the person(s) that fixes this!
I just created a virtualenv with pyvenv-3.4. pyvenv in Python 3.4 installs pip. Then I pip-installed flask with it as a test. That is, that all worked after I cleared the PYTHONPATH variable. I agree, burrito shouldn't modify the PYTHONPATH in the user's environment... although I haven't looked into that. Also, some of the things in PYTHONPATH were my own; this isn't the only case where one has to be careful using PYTHONPATH if you're switching between Pythons. I wish virtualenv / pyvenv allowed layering of venvs on venvs; the last time I tried that virtualenv barfed.
https://docs.python.org/3/library/venv.html
@switham Regarding setting PYTHONPATH, I'm tracking that in #55.
So has this been fixed?