I read that this should just work with the latest versions, here is what I'm getting: sontek@beast$ virtualenv --python=pypy ~/code/pypyenv Running virtualenv with interpreter /usr/bin/pypy New pypy executable in /home/sontek/code/pypyenv/bin/pypy ERROR: The executable /home/sontek/code/pypyenv/bin/pypy is not functioning ERROR: It thinks sys.prefix is u'/usr/lib64/pypy-1.5' (should be '/home/sontek/code/pypyenv') ERROR: virtualenv is not compatible with this system or executable sontek@beast$ pypy --version Python 2.7.1 (?, May 02 2011, 19:05:35) [PyPy 1.5.0-alpha0 with GCC 4.6.0] ~ sontek@beast$ virtualenv --version 1.6.4
Fedora 15 doesn't have 1.6 out yet. I tried to use the binary release but it seems to be compiled against different libssl/libcrypto's than what I have on my system... I symlinked them over but it fails to create the virtualenv still: sontek@beast$ virtualenv -p /home/sontek/Downloads/pypy16/pypy-1.6/bin/pypy /home/sontek/code/pypyenv2 Running virtualenv with interpreter /home/sontek/Downloads/pypy16/pypy-1.6/bin/pypy /home/sontek/Downloads/pypy16/pypy-1.6/bin/pypy: /usr/lib64/libssl.so.0.9.8: no version information available (required by /home/sontek/Downloads/pypy16/pypy-1.6/bin/pypy) /home/sontek/Downloads/pypy16/pypy-1.6/bin/pypy: /usr/lib64/libcrypto.so.0.9.8: no version information available (required by /home/sontek/Downloads/pypy16/pypy-1.6/bin/pypy) and then the directory isn't created. On Wed, Sep 28, 2011 at 5:41 PM, Maciej Fijalkowski <fijall@gmail.com>wrote:
sontek@beast$ virtualenv -p /usr/bin/pypy ~/code/eqpypy Running virtualenv with interpreter /usr/bin/pypy New pypy executable in /home/sontek/code/eqpypy/bin/pypy ERROR: The executable /home/sontek/code/eqpypy/bin/pypy is not functioning ERROR: It thinks sys.prefix is u'/usr/lib64/pypy-1.6' (should be '/home/sontek/code/eqpypy') ERROR: virtualenv is not compatible with this system or executable sontek@beast$ pypy --version Python 2.7.1 (?, Sep 12 2011, 23:40:42) [PyPy 1.6.0 with GCC 4.6.0] sontek@beast$ virtualenv --version 1.6.4 ppyp 1.6 is from http://koji.fedoraproject.org/koji/buildinfo?buildID=263267 On Wed, Sep 28, 2011 at 6:09 PM, John Anderson <sontek@gmail.com> wrote:
Hi, On Thu, Sep 29, 2011 at 03:16, John Anderson <sontek@gmail.com> wrote:
Try running just "pypy" and see if it prints the following warning lines: debug: WARNING: Library path not found, using compiled-in sys.path. debug: WARNING: 'sys.prefix' will not be set. debug: WARNING: Make sure the pypy binary is kept inside its tree of files. debug: WARNING: It is ok to create a symlink to it from somewhere else. If it does, well, follow the recommendation. If it doesn't, then likely, something is again broken in the interaction of virtualenv and pypy. Antonio, do you know if virtualenv 1.6.4 is supposed to work with pypy? A bientôt, Armin.
On Wed, 2011-09-28 at 18:09 -0400, John Anderson wrote:
Fedora 15 doesn't have 1.6 out yet. I tried to use the binary release
FWIW, pypy 1.6 for Fedora 15 can now be found in the fedora-updates-testing repository: https://admin.fedoraproject.org/updates/FEDORA-2011-13521 (though IIRC you said on #pypy that you ran into issues with that build also)
On Fri, 2011-09-30 at 17:14 -0400, John Anderson wrote:
Yeah, that build doesn't work with virtualenv.
Thanks - I've filed a bug about this in Fedora's downstream bug tracker here: https://bugzilla.redhat.com/show_bug.cgi?id=742641 [snip]
Fedora 15 doesn't have 1.6 out yet. I tried to use the binary release but it seems to be compiled against different libssl/libcrypto's than what I have on my system... I symlinked them over but it fails to create the virtualenv still: sontek@beast$ virtualenv -p /home/sontek/Downloads/pypy16/pypy-1.6/bin/pypy /home/sontek/code/pypyenv2 Running virtualenv with interpreter /home/sontek/Downloads/pypy16/pypy-1.6/bin/pypy /home/sontek/Downloads/pypy16/pypy-1.6/bin/pypy: /usr/lib64/libssl.so.0.9.8: no version information available (required by /home/sontek/Downloads/pypy16/pypy-1.6/bin/pypy) /home/sontek/Downloads/pypy16/pypy-1.6/bin/pypy: /usr/lib64/libcrypto.so.0.9.8: no version information available (required by /home/sontek/Downloads/pypy16/pypy-1.6/bin/pypy) and then the directory isn't created. On Wed, Sep 28, 2011 at 5:41 PM, Maciej Fijalkowski <fijall@gmail.com>wrote:
sontek@beast$ virtualenv -p /usr/bin/pypy ~/code/eqpypy Running virtualenv with interpreter /usr/bin/pypy New pypy executable in /home/sontek/code/eqpypy/bin/pypy ERROR: The executable /home/sontek/code/eqpypy/bin/pypy is not functioning ERROR: It thinks sys.prefix is u'/usr/lib64/pypy-1.6' (should be '/home/sontek/code/eqpypy') ERROR: virtualenv is not compatible with this system or executable sontek@beast$ pypy --version Python 2.7.1 (?, Sep 12 2011, 23:40:42) [PyPy 1.6.0 with GCC 4.6.0] sontek@beast$ virtualenv --version 1.6.4 ppyp 1.6 is from http://koji.fedoraproject.org/koji/buildinfo?buildID=263267 On Wed, Sep 28, 2011 at 6:09 PM, John Anderson <sontek@gmail.com> wrote:
Hi, On Thu, Sep 29, 2011 at 03:16, John Anderson <sontek@gmail.com> wrote:
Try running just "pypy" and see if it prints the following warning lines: debug: WARNING: Library path not found, using compiled-in sys.path. debug: WARNING: 'sys.prefix' will not be set. debug: WARNING: Make sure the pypy binary is kept inside its tree of files. debug: WARNING: It is ok to create a symlink to it from somewhere else. If it does, well, follow the recommendation. If it doesn't, then likely, something is again broken in the interaction of virtualenv and pypy. Antonio, do you know if virtualenv 1.6.4 is supposed to work with pypy? A bientôt, Armin.
On Wed, 2011-09-28 at 18:09 -0400, John Anderson wrote:
Fedora 15 doesn't have 1.6 out yet. I tried to use the binary release
FWIW, pypy 1.6 for Fedora 15 can now be found in the fedora-updates-testing repository: https://admin.fedoraproject.org/updates/FEDORA-2011-13521 (though IIRC you said on #pypy that you ran into issues with that build also)
On Fri, 2011-09-30 at 17:14 -0400, John Anderson wrote:
Yeah, that build doesn't work with virtualenv.
Thanks - I've filed a bug about this in Fedora's downstream bug tracker here: https://bugzilla.redhat.com/show_bug.cgi?id=742641 [snip]
participants (5)
-
Antonio Cuni -
Armin Rigo -
David Malcolm -
John Anderson -
Maciej Fijalkowski