Skip to content
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

mkvirtualenv fail python3 #24

Open
MichaelMartinez opened this issue Dec 14, 2012 · 15 comments
Open

mkvirtualenv fail python3 #24

MichaelMartinez opened this issue Dec 14, 2012 · 15 comments
Labels

Comments

@MichaelMartinez
Copy link

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
Copy link
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
Copy link

regebro commented Dec 14, 2012

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.

@bbinet
Copy link

bbinet commented Jan 18, 2013

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

@vfr292
Copy link

vfr292 commented May 17, 2013

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
Copy link
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
Copy link

vfr292 commented May 17, 2013

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
Copy link
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
Copy link

vfr292 commented May 18, 2013

Got it! Thanks again.

@zakdances
Copy link

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

@glyphobet
Copy link
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
Copy link
Owner

brainsik commented Dec 8, 2013

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
Copy link

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
Copy link

switham commented Apr 17, 2014

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

@brainsik
Copy link
Owner

@switham Regarding setting PYTHONPATH, I'm tracking that in #55.

@brainsik brainsik mentioned this issue Dec 9, 2016
@RustyRaptor
Copy link

So has this been fixed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

10 participants