Feature/cli redesign

[sschleemilch]

About (WIP - builds on top of #371)

Fixes #372

Cli using click

[!WARNING] Interface changes --include-dir -> --include-dirs -s --> --strict / --no-strict --abort-on-unknown-attribute -> --abort unknown-attribute --abort-on-name-style -> --abort name-style -q / --quantity_file -> --quantities / -q --unit_file -> --units / -u --gqlfield name description -> --qgl-field/-q name,description -vt / --vspec-types-file -> --types / -t -ot / --types-output-file -> --types-out --json-pretty -> --pretty --json-all-extended-attributes -> --extend-all-attributes --only-validate-no-export -> --validate-only --strict-mode -> Enabled via --strict --jsonschema-disallow-additional-properties -> --no-additional-properties --jsonschema-require-all-properties -> --require-all-properties --jsonschema-pretty -> --pretty

[!NOTE] New arguments vspec2binary: --bintool-dll/-b

[erikbosch]

Some comments/background information to current design. Some time ago we had something similar, see --format in for example https://github.com/COVESA/vss-tools/blob/v3.1/docs/vspec2x.md and https://github.com/COVESA/vss-tools/blob/v3.1/vspec2x.py

Some reasons why we changed the setup was:

• We wanted to make it easy to customize tooling to use your own generator (only), like in https://github.com/COVESA/vss-tools/blob/master/tests/generators/example_generator.py, without getting any python requirements (like graphlql) from other tools.
• We wanted for our Python builds (to upload to pypi) to exclude the "binary-tool", as it is difficult for us to build the c++ library for other platforms (building locally is fine), so we opted for not including the binary tool in the pypi package (as you then anyway need to download vss-tools and build the lib manually)
• Making it easy to remove tools from your own fork, like if you do not want franca (by any reason), just remove the *2franca.py files. Could be useful if you want to use vss-tools internally and you for license scanning reasons, vulnerability management or any other reason want to get rid of everything you do not need.

With this PR we go back a bit to how it was before, i.e. vspec2x.py explicitly containing/listing the tools. and it also becomes quite long. I do not know if it would be possible in some way to get a more dynamic design, where each method like def yaml_( is put in a separate file and not explicitly mentioned in vspec2x.py` to make it easy to add/remove tools.

[sschleemilch]

Good Point, I will investigate a bit whether ITS possible. If not we could keep different entry points like before. Click seems to support lazy subcommand loading: https://click.palletsprojects.com/en/8.1.x/complex/#lazily-loading-subcommands

Will try it out..

[sschleemilch]

Changed it back to previous entry points and left the original positional options like the vspec file and the output file. Changed a few arguments though to be more consistent. So personally the file layout and the cli options are a bit simpler now compared to the vspec2x base class and the config option before. Sure, now every tool cli has to redefine quite a lot cli arguments with the benefit of not needing a config object what a certain exporter supports. Because if the exporter has no cli argument for it, it does simply not support the feature.

[sschleemilch]

[adobekan]

MoM: follow up in a week.

[erikbosch]

Conflicts

[nwesem]

I really like this idea and I think even though it might break the current API, we should consider this for the next release (which would have to be 5.0? as it breaks a few things in terms of backwards compatibility, e.g. proplery renaming of the CLAs :grin:)

Edit: Also I would definitely vote for the lazy loading of subcommands

[sschleemilch]

I really like this idea and I think even though it might break the current API, we should consider this for the next release (which would have to be 5.0? as it breaks a few things in terms of backwards compatibility, e.g. proplery renaming of the CLAs 😁)

Edit: Also I would definitely vote for the lazy loading of subcommands

It is now here: #378