Fetch env variables from command line

[acerv]

Fade out --env option and support environment variables via command line.

[pevik]

Make sense.

[grisu48]

For the transition time, would it be a good idea to set those setting both via environment variables and via --env?

i.e. e.g. for the following run

python3.11 kirk ... --env TMPDIR=/var/tmp:LTP_VIRT_OVERRIDE=microsoft

Until this is implemented do

export TMPDIR=/var/tmp
export LTP_VIRT_OVERRIDE=microsoft
python3.11 kirk ... --env TMPDIR=/var/tmp:LTP_VIRT_OVERRIDE=microsoft

Here we would set the required settings both via environment variables and explicitly via --env, so whenever this transition happens either one of the two would still be applied and we should be safe, right?

[acerv]

The idea is to implement the new feature such as it is for OpenQA client commands, so we don't need the --env options anymore. For example:

kirk ... --env TMPDIR=/var/tmp:LTP_VIRT_OVERRIDE=microsoft

Will become:

TMPDIR=/var/tmp LTP_VIRT_OVERRIDE=microsoft kirk ...

And of course, export will be supported as well for more global assignment. It's better to remove --env completely at the very first commit implementing this feature, so please use the current release until you have time for update kirk command on your CI.

[pevik]

A side note: TMPDIR=/var/tmp LTP_VIRT_OVERRIDE=microsoft kirk and export TMPDIR=/var/tmp LTP_VIRT_OVERRIDE=microsoft; kirk are equivalent (both done by shell passing variable to python3 binary).

[mimi1vx]

it should support both

[acerv]

it should support both

Thanks for the suggestion. Unfortunately, this is one of those features where it's better to keep one feature only instead of duplicating code. If we support external variables via command line without --env, the change will be as easy as:

MYENV1=val1 MYENV2=val2 kirk --run-suite syscalls

instead of the following form which is way more difficult to read and to handle via CI:

kirk --run-suite syscalls --env MYENV1=val1:MYENV2=val2

[pevik]

it should support both

Thanks for the suggestion. Unfortunately, this is one of those features where it's better to keep one feature only instead of duplicating code. If we support external variables via command line without --env, the change will be as easy as:

Maybe @mimi1vx is referring to my note that export environment variable or passing unexported environment variable to the python binary is the same (that's how shell works). I.e. he's might not be suggesting to keep both new functionality respecting environment variables and keeping the old --env.

Anyway, I also vote to drop the old --env.