Simplify Command Line Interface

[markuspi]

Is your feature request related to a problem? Please describe.
Most popuar static code checking tools and linters offer a simple command line interface, where a set of rules is enabled by default, and one or more files can be checked by passing their names as additional arguments.
Currently, qc_runtime does not follow this approach due to several issues:

1. The runtime depends on C++ modules which takes effort to set up, especially on Windows
2. The checks have to be enabled one-by-one in the config file
3. The file to be checked has to be written into the config file

A simple and easy to install command line interface would also greatly simplify integration into CI/CD toolchains.

Describe the solution you'd like

1. The command line tool should be trivial to install, e.g. by implementing it in pure Python, see also Replace C++ based TextReport module with Python implementation #115
2. A set of checks should be enabled by default, or sets of checks should be easily selectable, possibly related to Implicit checker selection based on rule configuration #20
3. The command line tool should directly accept one or more paths to files which are about to be checked.

Describe alternatives you've considered

• Providing a Docker environment is not a satisfactory solution as Docker is not available in all environments. The resource overhead also seems disproportionate given the scope of functionality provided by qc_runtime.
• Additional wrapper scripts like demo_pipeline/configuration_generator.py add unnecessary complexity. This functionality should be directly part of a command line interface

[andreaskern74]

@markuspi : Thanks for this issue. I also struggled with the current situation. But it was/is difficult to create a solution, which is flexible enough and at the same time easy enough for new users or people to understand, who just want to execute the provided ASAM checks without adding additional Checker Libraries.

One first (fast and easy) step may be that

• 'qc_runtime' get two new input parameters: the input_file and the configuration template, or if input_file is given by the user, then the configuration file is used as template --> IMHO this fulfills most of the use cases in production environment, because the user know its file type, which is passed to 'qc_runtime'.
• The demo pipeline could be moved out of qc-framework into a new repo/delivery to reduce user distraction. Then it's also possible to create different versions for the pipeline. Also a classic one, no Docker, Windows, ... qc-framework should be standard agnostic and should know nothing about individual standards.

This is not the final solution you like, but probably a step into this direction. We need to discuss these topic with the other partners.

[hoangtungdinh]

Hi @markuspi, @andreaskern74,

I share the same struggle and also think that this topic is one of the high priorities for the next iteration.

Besides the solution suggested by @andreaskern74, there are two other options we can consider to make it easier for the user to "just use" the framework and default checker bundles.

1. Long-term option

Currently Docker is used to build ResultPooling and TextReport. Given their functionality, it is possible to rewrite them in Python. Once they are in Python, we can create a "meta" module in Python that contains all the standard checker bundles, qc_runtime, ResultPooling, TextReport. This module also contains manifest files and something similar to demo_pipeline/configuration_generator.py (or something simpler) as an entry point.

With a single pip install, users can install this meta module, which will also automatically install other necessary dependencies. And then using it will be as simple as qc_meta... input_file. Users can also register any additional checker bundles using the manifest file mechanism.

This module can be outside of qc-framework.

2. Short-term option

It is possible to include pre-built C++ modules directly into a Python package for distribution, which doesn't require rewriting ResultPooling and TextReport in Python. However, we have to manually build the C++ binaries and add them to the distribution. And this approach may not work for companies that require binaries to be built from source.

[AsamDiegoSanchez]

Agreed on the CCB to me tagged as Wishlist.

The way we see it, there are two distinct user profiles for the QC framework: developers who implement and register checks, and users who want to run checks on their files. This issue is more relevant to the latter group, aiming to make the framework easier for them to use.
Currently, users can run checks using a Docker-based demo pipeline or by installing components individually. However, Docker is not always available, especially on Windows, which complicates the process for some users.
Several options were discussed to simplify the process, including updating the QC runtime to accept a template configuration file or creating a meta package for easy installation through a single command. These options aim to streamline the process for users who are not developers.
But after the initial discussions it was agreed, that is it something that can be done in the next QC iteration