Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

mkvirtualenv fail python3 #24

Open
MichaelMartinez opened this Issue · 13 comments

9 participants

@MichaelMartinez

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

@glyphobet
Collaborator

@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.

@regebro

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.

@glyphobet glyphobet referenced this issue
Closed

Python2, please #25

@bbinet

I'm also facing this bug (using virtualenv-burrito on debian): mkvirtualenv -p python3 myvenv will generate the same error as @MichaelMartinez reported.

@vfr292

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.

@glyphobet
Collaborator

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.

@vfr292

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.

@glyphobet
Collaborator

To uninstall:

  1. 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
  1. Remove your ~/.venvburrito/ directory
@vfr292

Got it! Thanks again.

@zakdances

I've run into this same issue. Would a pull request fix be considered?

@glyphobet
Collaborator

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.

@brainsik
Owner

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.

@jonathan-s

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!

@switham

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.