Issue2329

This is what happens when I try to create a virtualenv using jython 2.7rc2 (linked to /usr/local/bin/jython on my machine)
```
[~]$ /usr/bin/python -m virtualenv --setuptools --python /usr/local/bin/jython jython
Running virtualenv with interpreter /usr/local/bin/jython
Using real prefix '/Users/clara/jython'
Cannot find file /Users/clara/jython/cachedir (bad symlink)
New jython executable in jython/bin/jython
ERROR: The executable jython/bin/jython is not functioning
ERROR: It thinks sys.prefix is u'/Users/clara/jython_2.7rc2' (should be u'/Users/clara/jython')
ERROR: virtualenv is not compatible with this system or executable
```

Unsure if already reported... couldn't find another issue that covers this

I also have run into this. Depending on your platform, it's possible to get past this by switching between the CPython-based launcher and the bash-based launcher (and/or a newer virtualenv release). Unfortunately, if you do, then you run into not being able to install pip and setuptools:

$ mkvirtualenv -p dist/bin/jython.py ./jydist2
Running virtualenv with interpreter /jython/dist/bin/jython.py
Cannot find file /jython/dist/Include (bad symlink)
New jython executable in ./jydist2/bin/jython.py
Installing setuptools, pip...
  Complete output from command /...ydist2/bin/jython.py -c "import sys, pip; sys...d\"] + sys.argv[1:]))" setuptools pip:
  Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named pip
----------------------------------------
...Installing setuptools, pip...done.
Traceback (most recent call last):
  File "/site-packages/virtualenv.py", line 2352, in <module>
    main()
  File "//virtualenv.py", line 816, in main
    create_environment(home_dir,
  File "//site-packages/virtualenv.py", line 993, in create_environment
    install_wheel(to_install, py_executable, search_dirs)
  File "//site-packages/virtualenv.py", line 955, in install_wheel
    call_subprocess(cmd, show_stdout=False,
  File "//site-packages/virtualenv.py", line 901, in call_subprocess
    raise OSError(
OSError: Command /...ydist2/bin/jython.py -c "import sys, pip; sys...d\"] + sys.argv[1:]))" setuptools pip failed with error code 1

What virtualenv wants to do is put its own specific .whl files on the PYTHONPATH environment variable. It seems that Jython doesn't support wheels on the PYTHONPATH (but I haven't confirmed that). Even if it did, though, there's an incompatibility with a recent pip that's forcing Jython to bundle its own. So until that incompatibility is fixed and a new virtualenv is released with it, I'm afraid virtualenv isn't going to work (unless we can find some workaround in Jython itself), regardless of PYTHONPATH issues. 

Then again, virtualenv also has a tradition of including implementation-specific code for each platform it runs on. For example, it knows that Jython's directory is called "Lib" and not "lib". So maybe after the final release (or a near-enough final release) the virtualenv and Jython maintainers can work together to solve the issue.

I'm happy to help test and debug, time permitting. Being able to use jython with 'tox' is a semi-blocker for official Jython support in a lot of the Zope projects I help with.

Sure enough, virtualenv is putting wheels on 'PYTHONPATH', but Jython wants to read from 'JYTHONPATH' (?). If I change one or the other of them so that they agree on the environment variable, sure enough, the Pip incompatibility surfaces (with both virtualenv 12.0.7 and 12.1.1):

$ mkvirtualenv -p dist/bin/jython.py ./jydist2
Running virtualenv with interpreter /Users/jmadden/Projects/GithubSources/jython/dist/bin/jython.py
Cannot find file /Users/jmadden/Projects/GithubSources/jython/dist/Include (bad symlink)
New jython executable in ./jydist2/bin/jython.py
Installing setuptools, pip...
  Complete output from command /Users/jmadden/Proje...ydist2/bin/jython.py -c "import sys, pip; sys...d\"] + sys.argv[1:]))" setuptools pip:
  Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "//site-packages/virtualenv_support/pip-6.1.1-py2.py3-none-any.whl/pip/__init__.py", line 15, in <module>
  File "//site-packages/virtualenv_support/pip-6.1.1-py2.py3-none-any.whl/pip/vcs/subversion.py", line 9, in <module>
  File "//site-packages/virtualenv_support/pip-6.1.1-py2.py3-none-any.whl/pip/index.py", line 30, in <module>
  File "//site-packages/virtualenv_support/pip-6.1.1-py2.py3-none-any.whl/pip/_vendor/__init__.py", line 83, in load_module
  File "//site-packages/virtualenv_support/pip-6.1.1-py2.py3-none-any.whl/pip/_vendor/__init__.py", line 72, in load_module
  File "/site-packages/virtualenv_support/pip-6.1.1-py2.py3-none-any.whl/pip/_vendor/html5lib/__init__.py", line 16, in <module>
  File "//site-packages/virtualenv_support/pip-6.1.1-py2.py3-none-any.whl/pip/_vendor/html5lib/html5parser.py", line 6, in <module>
UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in position 47-53: illegal Unicode character
----------------------------------------

For what it's worth this crops up when creating virtualenvs in Tox as well -- which would seem to preclude driving changes using CLI/env tweaks. I'd certainly expect this to work in tools that are generally only aware of python interpreters as executables.

Yes, I concur with both @offby1 and the OP: this also shows up in Tox. I got as far as I did with plain virtualenv by adapting the code either in it or in or jython, neither of which is a generally workable solution for tox (or the typical tox user), and neither of which solves the problem in recent releases. But I was motivated to try specifically for tox :)

I created a pull request for virtualenv at https://github.com/pypa/virtualenv/pull/746. You can grab the branch it comes from to use virtualenv with current jython builds. I have no idea if it will be accepted (or when) as the virtualenv maintainers are in the middle of a massive rewrite.

There's a spurious message about a missing Include directory (there is not one in Jython itself, because we are on Java!), but it looks like we can start the process of closing this bug out on bugs.jython.org.

After installing current virtualenv with each:

$ python -m virtualenv --setuptools --python ~/jython2.7.1/bin/jython virtualenv-jython
Running virtualenv with interpreter /Users/jbaker/jython2.7.1/bin/jython
Using real prefix '/Users/jbaker/jython2.7.1'
Cannot find file /Users/jbaker/jython2.7.1/Include (bad symlink)
New jython executable in virtualenv-jython/bin/jython
Installing setuptools, pip, wheel...done.

$ ~/jython2.7.1/bin/jython -m virtualenv --setuptools --python ~/jython2.7.1/bin/jython virtualenv-jython-from-jython
Already using interpreter /Users/jbaker/jython2.7.1/bin/jython
Using real prefix '/Users/jbaker/jython2.7.1'
Cannot find file /Users/jbaker/jython2.7.1/Include (bad symlink)
New jython executable in virtualenv-jython-from-jython/bin/jython
Installing setuptools, pip, wheel...done.

$ ls /Users/jbaker/jython2.7.1/Include
ls: /Users/jbaker/jython2.7.1/Include: No such file or directory

(Also I'm running using what will be in the release candidate next week, which has current pip and setuptools wheels from upstream instead of Jython-specific ones.)

somewhat different issue but tox related
tox
jython create: /Users/darjus/Documents/tox_test/.tox/jython
ERROR: InvocationError: Failed to get version_info for jython: could not decode "{'version_info': sys.version_info(major=2, minor=7, micro=2, releaselevel='beta', serial=0), 'sysplatform': 'java1.7.0_80'}\n"

Darjus, didn't you fix sys.version_info in #2380? Wonder what's going on here.

Hey Jim, check this out: https://github.com/jythontools/jython/commit/c8b0ededaabe45bc0d102b9adc98cc38ae5c1aa6

basically because of our PyTuple behavior, if you just extend PyTuple, we don't really create a new tuple, which is a problem.

New issue now.

Traceback (most recent call last):
  File "/Library/Python/2.7/site-packages/virtualenv.py", line 26, in <module>
    if sys.version_info < (2, 6):
RuntimeError: maximum recursion depth exceeded (Java StackOverflowError)

shoot, the new issue is because of me using PyTupleDerived :-/

Right, I would have thought it should be

public class PyVersionInfo extends PyTuple { ... }

not the current

public class PyVersionInfo extends PyTupleDerived { ... }

Should be now fixed with https://hg.python.org/jython/rev/636b124a7587

The StackOverflow error was fixed by https://hg.python.org/jython/rev/03f797ecd7ea