You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently ./rally is unable to detect virtualenvs created with pyvenv (which is the case when pyenv is installed).
The reason is that while sys.real_prefix is defined with regular Virtualenv's (such as the one created with python3 -m venv venv or virtualenv -p python3 venv) it is not defined when pyvenv is in use. In other words, if a user has installed pyvenv locally or globally, which is a requirement for integration tests anyway, in some platforms this takes over when creating virtualenv's even with python3 -m venv venv.
No sys.real_path in Python3 when pyvenv is in use
$ pyenv shell 3.6.4
$ which python3
~/.pyenv/shims/python3
$ python3 --version
Python 3.6.4
$ python3 -m venv venv
$ source venv/bin/activate
(venv) dl@MS-7885 ~ $ python3
Python 3.6.4 (default, Mar 12 2018, 11:20:13)
[GCC 7.3.1 20180130 (Red Hat 7.3.1-2)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.real_prefix
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: module 'sys' has no attribute 'real_prefix'
>>> sys.base_prefix
'/home/dl/.pyenv/versions/3.6.4'
>>> sys.prefix
'/home/dl/venv'
The text was updated successfully, but these errors were encountered:
This commit fixes two issues. Firstly, let `./rally` start when
executed for the first time with self update disabled (e.g. from a non
master branch in a fork) by ensuring the `esrally` binary has been
installed with setuptools.
Secondly, fix virtualenv detection when pyenv is in use. On some
configurations when pyenv is present, creating a Python3 virtualenv
uses pyvenv instead of Python3's own virtualenv[1] which fails the
current check for a virtualenv in the `run.sh` script.
[1] https://legacy.python.org/dev/peps/pep-0405/Closeselastic#447Closeselastic#448
This commit fixes two issues. Firstly, let `./rally` start when
executed for the first time with self update disabled (e.g. from a non
master branch in a fork) by ensuring the `esrally` binary has been
installed with setuptools.
Secondly, fix virtualenv detection when pyenv is in use. On some
configurations when pyenv is present, creating a Python3 virtualenv
uses pyvenv instead of Python3's own virtualenv[1] which fails the
current check for a virtualenv in the `run.sh` script.
[1] https://legacy.python.org/dev/peps/pep-0405/
Relates #449Closes#447Closes#448
Currently
./rally
is unable to detect virtualenvs created with pyvenv (which is the case whenpyenv
is installed).The reason is that while sys.real_prefix is defined with regular Virtualenv's (such as the one created with
python3 -m venv venv
orvirtualenv -p python3 venv
) it is not defined whenpyvenv
is in use. In other words, if a user has installedpyvenv
locally or globally, which is a requirement for integration tests anyway, in some platforms this takes over when creating virtualenv's even withpython3 -m venv venv
.No sys.real_path in Python3 when pyvenv is in use
The text was updated successfully, but these errors were encountered: