[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v6 08/11] iotests: add testenv.py

From: Vladimir Sementsov-Ogievskiy
Subject: Re: [PATCH v6 08/11] iotests: add testenv.py
Date: Mon, 18 Jan 2021 20:00:25 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1

18.01.2021 12:59, Kevin Wolf wrote:
Am 16.01.2021 um 12:03 hat Vladimir Sementsov-Ogievskiy geschrieben:
15.01.2021 16:30, Vladimir Sementsov-Ogievskiy wrote:
15.01.2021 16:20, Kevin Wolf wrote:
Am 15.01.2021 um 14:10 hat Vladimir Sementsov-Ogievskiy geschrieben:
15.01.2021 15:45, Kevin Wolf wrote:
Am 15.01.2021 um 13:19 hat Vladimir Sementsov-Ogievskiy geschrieben:
15.01.2021 14:18, Kevin Wolf wrote:
Am 09.01.2021 um 13:26 hat Vladimir Sementsov-Ogievskiy geschrieben:
Add TestEnv class, which will handle test environment in a new python
iotests running framework.

Difference with current ./check interface:
- -v (verbose) option dropped, as it is unused

- -xdiff option is dropped, until somebody complains that it is needed
- same for -n option

Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
    tests/qemu-iotests/testenv.py | 328 ++++++++++++++++++++++++++++++++++
    1 file changed, 328 insertions(+)
    create mode 100755 tests/qemu-iotests/testenv.py


+    def init_binaries(self):
+        """Init binary path variables:
+             PYTHON (for bash tests)
+             SOCKET_SCM_HELPER
+        """
+        self.python = '/usr/bin/python3 -B'

This doesn't look right, we need to respect the Python binary set in
configure (which I think we get from common.env)

Oh, I missed the change. Then I should just drop this self.python.

Do we still get the value from elsewhere or do we need to manually parse

Hmm.. Good question. We have either parse common.env, and still create 
self.python variable.

Or drop it, and include common.env directly to bash tests. For this we'll need 
to export

  . $BUILD_IOTESTS/common.env

in common.rc..

check uses it, too, for running Python test cases.

But new check (written in python) doesn't.. Should I keep bash check, which 
will have only one line to call check.py with help of PYTHON?

Or finally, may be just drop it? Can we just use system python for
tests, now when we are already in a python3 world?

You can only assume the Python 3 (or more specifically 3.6+) world if
you are using the Python interpreter that was passed to configure. This
will commonly be the same thing as the first python3 in PATH, but it
doesn't have to be.

So your solution of just using the same interpreter as for check might
be okay as long as we make sure that 'make check' calls check with the
configured Python interpreter instead of relying on the shebang line.

I've sent v7 with exactly this thing: use same interpreter as for check and 
adjust check-block.sh which is called from make check

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]