Add runtime instructions #680
Conversation
| $ pip3 --quiet install --upgrade pip | ||
| $ pip3 --quiet install tox --ignore-installed six |
There was a problem hiding this comment.
Maybe add a --user flag here?
| $ pip3 --quiet install --upgrade pip | |
| $ pip3 --quiet install tox --ignore-installed six | |
| $ pip3 --quiet install --user --upgrade pip | |
| $ pip3 --quiet install --user tox --ignore-installed six |
There was a problem hiding this comment.
I think we should advertise installation of packages, or if that is unwanted for some reason, advertise the use of venvs instead of pip install globally (or as user which is also not possible on tumbleweed)
There was a problem hiding this comment.
I do like to advertise the use of venvs more than using the --user flag, so I added instructions to use a virtualenv.
By using the --user flag we need to explain that this will only work outside of virtualenvs and it's also not what we are using in our test flow in openQA, so I think that's not what we should document.
There was a problem hiding this comment.
actually I'd prefer if we wouldn't use the pip method in openQA either from a supply chain security perspective..
There was a problem hiding this comment.
Let's make this a meeting point on Tuesday, that requires more more engineering work especially on older versions (12-SP5) but if we want to do this, it should be possible.
For now I suggest we decouple this initiative from this PR, because that's not easy to solve and not worth waiting for IMHO.
| .. code-block:: shell-session | ||
|
|
||
| $ sudo zypper -n in podman buildah docker git-core python3 python3-pip | ||
| $ pip3 --quiet install --upgrade pip |
There was a problem hiding this comment.
why not simply install python3-pip (or python311-pip) instead? seems simpler than this process imho.
There was a problem hiding this comment.
But python3-pip is installed just in the line before. This is there to update pip, which we do, but I'm not sure if that's really needed.
There was a problem hiding this comment.
It's not needed. but you should be installing python311 instead which is 3.11 rather than 3.6.
There was a problem hiding this comment.
This also needs to work on older versions, so this is the most generic version that will work at least on Leap and Tumbleweed.
If we advance to specifying python311 it will not work on Leap and require us to update the documentation every time there is a Leap release or Tumbleweed updates the major python version in use.
For the sake of making the document age better, I would stay with the generic version.
README.rst
Outdated
|
|
||
| # export OS_VERSION=15.6 # Target SLES version | ||
| # export CONTAINER_RUNTIME=podman # Defaults to podman | ||
| # export TARGET=ibs-cr # ibs-cr = ToTest, ibs = SUSE:SLE-15-SP*:Update:BCI, obs = devel:BCI:*, factory-totest = Factory |
There was a problem hiding this comment.
I think this is great, but we should have a section for each environment variable explaining what it means? happy to help with this myself.
There was a problem hiding this comment.
I've added a separate block now, please check again if that matches what you meant.
|
|
||
| .. code-block:: shell-session | ||
|
|
||
| $ sudo zypper -n in podman buildah docker git-core python3 python3-pip |
There was a problem hiding this comment.
so is this supposed to be run inside the venv or outside? if it's inside the venv, you don't need to install python3-pip anymore, it is provided by the venv.
There was a problem hiding this comment.
True only if running in a venv. I phrased the previous block as optional so in cases where people run this outside a venv (for whatever reasons) it would still be needed.
Adds instructions for installing dependencies and optional environment variables that might help users.
|
I'm reviving this MR. @dirkmueller @dcermak can you please take a look if we can merge this? |
| It is recommended to run BCI tests in its own virtual environment by doing the following: | ||
|
|
||
| .. code-block:: shell-session | ||
|
|
||
| $ sudo zypper in python3-virtualenv | ||
| $ virtualenv .bci_tester | ||
| $ source .bci_tester/bin/activate | ||
|
|
||
| Once the virtual environment `.bci_tester` has been setup, you only need to run `source .bci_tester/bin/activate` again to activate it. |
There was a problem hiding this comment.
Tbh, I think this whole section is obsolete. I haven't activated a virtualenv in bci-tests since we introduced the venv toxenv.
There was a problem hiding this comment.
True, tox should run its own virtual env AFAIK
There was a problem hiding this comment.
But tox itself would be on the system itself, and currently the way to go is via pip, no?
There was a problem hiding this comment.
It shouldn't matter where you get tox from
There was a problem hiding this comment.
This virtualenv is for tox itself and therefore I consider it still relevant.
Especially on older SLES versions pip is the only way how to get this running and there it might be a good idea to contain it in it's own virtualenv.
Or am I wrong?
There was a problem hiding this comment.
I have never installed pip into a virtualenv, I'd go with pipx or use pip install --user.
There was a problem hiding this comment.
Not sure if there's anything older than py3.6 on SLE15, and in theory the tests work on that, I have no issues on Leap, but I often use venv if I want a new python version and to not install any packages on my system/user.
Most python users should be aware of poetry, venv, pipx, and so on, and might not want to use one option over another. Perhaps it is ok to ignore this step as it could be a user preference.
| It is recommended to run BCI tests in its own virtual environment by doing the following: | ||
|
|
||
| .. code-block:: shell-session | ||
|
|
||
| $ sudo zypper in python3-virtualenv | ||
| $ virtualenv .bci_tester | ||
| $ source .bci_tester/bin/activate | ||
|
|
||
| Once the virtual environment `.bci_tester` has been setup, you only need to run `source .bci_tester/bin/activate` again to activate it. |
There was a problem hiding this comment.
True, tox should run its own virtual env AFAIK
|
|
||
| .. code-block:: shell-session | ||
|
|
||
| $ export OS_VERSION=15.6 # Target SLES version |
There was a problem hiding this comment.
It would be nice to document all defaults in case nothing is set.
Adds instructions for installing dependencies and optional environment variables that might help users.