I like the concept and have been playing around with it. From my understanding, the test-python-x.y.py scripts act as set-up/staging scripts that do two things:
- Specify QRT-Depends, QRT-Packages, and the version of Python being tested:
This looks at the hard coded line in the source of test-python-x.y.py which specifies the Python version (and other package dependencies). This is where the implementation of an argv/single source script fails (for the current process) since the version would not be part of the source code when vm-qrt runs.
Hey Alex,
I like the concept and have been playing around with it. From my understanding, the test-python-x.y.py scripts act as set-up/staging scripts that do two things:
- Specify QRT-Depends, QRT-Packages, and the version of Python being tested:
# QRT-Depends: test-python.py 'python3. 10'
# QRT-Packages: python3.10 netcat-openbsd w3m
.
.
.
PYTHON=
- Runs 'test-python.py' (providing PYTHON as an arg) which is the script containing all the qa unit tests:
subprocess. Popen([ 'python2', 'test-python.py', PYTHON]
When I want to get these over on a VM to test, I use:
$ vm-qrt -p sec-impish-amd64 test-python3.10.py
At one point, vm-qrt runs:
$ grep 'QRT-Packages' ./`basename $test_script`
$ sudo apt-get install -y --force-yes <QRT-Packages>
This looks at the hard coded line in the source of test-python-x.y.py which specifies the Python version (and other package dependencies). This is where the implementation of an argv/single source script fails (for the current process) since the version would not be part of the source code when vm-qrt runs.