feat(all): Add global parameters

[nuclearcat]

1)Moving load_toml to main file, as it is common for all files. 2)Adding context to forward instance and settings to subcommands 3)Modifying at least "commit" subcommand to support latest Pipeline API 4)Add automatic repo info retrieval for "commit" with option to override by cli arguments.

[aliceinwire]

can you please divide this pr in small change as is difficult to review all toghether

[nuclearcat]

ok

[aliceinwire]

also I don't understand why you want to merge commit and patch with a general kci-dev.toml instead of keeping the current configuration file and trying to move away from standard click usage implementing a ctx context

[nuclearcat]

settings have identical functionality, it make sense to make it somewhere single place instead of duplicating function on each subcommand.
As i recall context also standard click feature, if you want to have global options that are identical for all subcommands (and instance+settings are indeed same for all subcommands).

[aliceinwire]

python2 as been deprecated years ago
python2 shebang is "#!/usr/bin/env python2"

python is usually just a symlink to your distribution python version
your distribution should be able to decide the correct python version for you

[nuclearcat]

According to PEP 394, For Python script publishers:

"Older Linux distributions will provide a python command that refers to Python 2, and will likely not provide a python2 command."
"Some Linux distributions will not provide a python command at all by default, but will provide a python3 command by default."

In my case (Debian bookworm) python is not provided at all (unless i install python-is-python3), so it is preferable to point to python3 which is supposed to work for all.

[aliceinwire]

we should change all the python file not just this one file

[nuclearcat]

we should change all the python file not just this one file

Good point, will change all.

[nuclearcat]

My point is that if we will have for example 4 subcommands (jobretry, commit, patch, patchset), we will have to duplicate --settings and load_toml in each file. So i am applying DRY principle and found way to make it shared, i think only way to do that is to make this option as global, as is it is mostly identical.
Also it opens way to add convenient option --instance, where we can test first some feature on local instance, then make PR and test on staging, and then if all ok - production. This is somehow similar concept how kernelci.toml works in kci(kernelci-core).

[aliceinwire]

My point is that if we will have for example 4 subcommands (jobretry, commit, patch, patchset), we will have to duplicate --settings and load_toml in each file. So i am applying DRY principle and found way to make it shared, i think only way to do that is to make this option as global, as is it is mostly identical. Also it opens way to add convenient option --instance, where we can test first some feature on local instance, then make PR and test on staging, and then if all ok - production. This is somehow similar concept how kernelci.toml works in kci(kernelci-core).

my idea about this was to move such duplicated code to a sort of common library script file, and just call the kernelci.toml reading function on each sub-command as needed. This would make each sub-command more flexible but still preventing to duplicate code.

[nuclearcat]

My point is that if we will have for example 4 subcommands (jobretry, commit, patch, patchset), we will have to duplicate --settings and load_toml in each file. So i am applying DRY principle and found way to make it shared, i think only way to do that is to make this option as global, as is it is mostly identical. Also it opens way to add convenient option --instance, where we can test first some feature on local instance, then make PR and test on staging, and then if all ok - production. This is somehow similar concept how kernelci.toml works in kci(kernelci-core).

my idea about this was to move such duplicated code to a sort of common library script file, and just call the kernelci.toml reading function on each sub-command as needed. This would make each sub-command more flexible but still preventing to duplicate code.

Agree, if it is common function that still have to be present on each subcommand (for example API call wrapper).
Also i think load_toml i can move to such common library.
But i think if each subcommand have common settings file, --settings logically should be global option?

[aliceinwire]

My point is that if we will have for example 4 subcommands (jobretry, commit, patch, patchset), we will have to duplicate --settings and load_toml in each file. So i am applying DRY principle and found way to make it shared, i think only way to do that is to make this option as global, as is it is mostly identical. Also it opens way to add convenient option --instance, where we can test first some feature on local instance, then make PR and test on staging, and then if all ok - production. This is somehow similar concept how kernelci.toml works in kci(kernelci-core).

my idea about this was to move such duplicated code to a sort of common library script file, and just call the kernelci.toml reading function on each sub-command as needed. This would make each sub-command more flexible but still preventing to duplicate code.

Agree, if it is common function that still have to be present on each subcommand (for example API call wrapper). Also i think load_toml i can move to such common library. But i think if each subcommand have common settings file, --settings logically should be global option?

right, so I think we can go with your patch.

[aliceinwire]

This PR looks good just be sure to have reformatted everything with python black (https://black.readthedocs.io/en/stable/index.html)

[nuclearcat]

Regarding load_toml, to place in some common library, where do you prefer to put it / name this library?
kci-dev/common.py
kci-dev/libs/common.py?
Sure common and libs can be changed.
Would like to know your preference.

[aliceinwire]

kci-dev/libs/common.py looks better

thanks for helping on this

[aliceinwire]

I added isort and python black check with GitHub action through poetry
could you rebase over main?
the import order change could have created some conflicts
For reference: #8

[nuclearcat]

sure, will do today

[nuclearcat]

I will do by small bits for now, i will open separate PR for --instance support and few more things

[aliceinwire]

I will do by small bits for now, i will open separate PR for --instance support and few more things

thanks you