On 5/13/22 02:06, John Snow wrote:
> Essentially, this:
>
> (A) adjusts the python binary to be the one found in the venv (which is
> a symlink to the python binary chosen at configure time)
>
> (B) adds a new VIRTUAL_ENV export variable
>
> (C) changes PATH to front-load the venv binary directory.
>
(amending my commit message/rfc notes while I'm here:)
I'll add that this way of entering a venv is more complex than the method used for VM tests and Avocado tests because it allows the possibility of shell tests (et al) invoking python utilities and having those be "in the venv" as well.
i.e. it's more rigorous and it matches the behavior of the "activate" shell script bundled with every venv.
> If the venv directory isn't found, raise a friendly exception that tries
> to give the human operator a friendly clue as to what's gone wrong. In
> the very near future, I'd like to teach iotests how to fix this problem
> entirely of its own volition, but that's a trick for a little later.
>
> Signed-off-by: John Snow <jsnow@redhat.com>
> ---
> tests/qemu-iotests/testenv.py | 24 +++++++++++++++++-------
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/tests/qemu-iotests/testenv.py b/tests/qemu-iotests/testenv.py
> index 0007da3f06c..fd3720ed7e7 100644
> --- a/tests/qemu-iotests/testenv.py
> +++ b/tests/qemu-iotests/testenv.py
> @@ -65,8 +65,9 @@ class TestEnv(ContextManager['TestEnv']):
> # lot of them. Silence pylint:
> # pylint: disable=too-many-instance-attributes
>
> - env_variables = ['PYTHONPATH', 'TEST_DIR', 'SOCK_DIR', 'SAMPLE_IMG_DIR',
> - 'PYTHON', 'QEMU_PROG', 'QEMU_IMG_PROG',
> + env_variables = ['PYTHONPATH', 'VIRTUAL_ENV', 'PYTHON',
> + 'TEST_DIR', 'SOCK_DIR', 'SAMPLE_IMG_DIR',
> + 'QEMU_PROG', 'QEMU_IMG_PROG',
> 'QEMU_IO_PROG', 'QEMU_NBD_PROG', 'QSD_PROG',
> 'QEMU_OPTIONS', 'QEMU_IMG_OPTIONS',
> 'QEMU_IO_OPTIONS', 'QEMU_IO_OPTIONS_NO_FMT',
> @@ -98,6 +99,10 @@ def get_env(self) -> Dict[str, str]:
> if val is not None:
> env[v] = val
>
> + env['PATH'] = os.pathsep.join((
> + os.path.join(self.virtual_env, 'bin'),
> + os.environ['PATH']
> + ))
> return env
>
> def init_directories(self) -> None:
> @@ -107,13 +112,17 @@ def init_directories(self) -> None:
> SOCK_DIR
> SAMPLE_IMG_DIR
> """
> -
> - # Path where qemu goodies live in this source tree.
> - qemu_srctree_path = Path(__file__, '../../../python').resolve()
> + venv_path = Path(self.build_root, 'tests/venv/')
> + if not venv_path.exists():
> + raise FileNotFoundError(
> + f"Virtual environment \"{venv_path!s}\" isn't found."
> + " (Maybe you need to run 'make check-venv'"
> + " from the build dir?)"
> + )
> + self.virtual_env: str = str(venv_path)
>
> self.pythonpath = os.pathsep.join(filter(None, (
> self.source_iotests,
> - str(qemu_srctree_path),
> os.getenv('PYTHONPATH'),
> )))
>
> @@ -138,7 +147,7 @@ def init_binaries(self) -> None:
> PYTHON (for bash tests)
> QEMU_PROG, QEMU_IMG_PROG, QEMU_IO_PROG, QEMU_NBD_PROG, QSD_PROG
> """
> - self.python = sys.executable
> + self.python: str = os.path.join(self.virtual_env, 'bin', 'python3')
Is this guaranteed even if, say, only a /usr/bin/python3.9 exists?
os.path.basename(sys.executable) might be more weirdness-proof than
'python3'.
Paolo
It *should*, because "#!/usr/bin/env python3" is the preferred shebang for Python scripts.
'python3' "should" be available. 'python' may not be.
Probably the "python" name in Makefile for TESTS_PYTHON should actually be "python3" as well. In practice, all permutations (python, python3, python3.9, etc.) are symlinks* to the binary used to create the venv. Which links are present may be site configurable, but pep394 should guarantee that python3 is always available.
(* not on Windows, where it'll be a copy.)