Install points to discuss

[tschmidtb51]

Points to discuss :

1) How to distribute the config file? For now it's inside the package, shall we put it inside /etc/, /usr/local/share or some other path?

See: https://github.com/csaf-tools/CVRF-CSAF-Converter/blob/issue/20-install-package/cvrf2csaf/common/utils.py#L12

2) Usage through CLI command is now possible, shall it be also possible to use it as a python module? (e.g. import cvrf2csaf; cvrf2csaf.convert(...))

Originally posted by @sustefil in https://github.com/csaf-tools/CVRF-CSAF-Converter/pull/23#issue-1094486032

[sthagen]

From the side lines I throw in some random ideas (🙈):

• The current config might as well be two environment variables - just sayin' ...
• Do I understand correctly, that for these two (key, value) pairs we introduce a dependency to PyYAML?
  • why not a json file that would make one less external dependency
  • an ini file would also do and need no external tool configparser would do
• In case we really want a configuration file, why not provide a least surprising loading strategy trying in the following order
  • command line arguments
  • environment variables
  • dot-file in well known places like
  • user home
  • and only last option to use source settings
• Users also tend to feel more empowered (faced with complex structure or values with non-obvious consequences)
  • when there is a command / command line option they can use to
  • receive on stdout a valid configuration file dumped with the default values.

[tschmidtb51]

1) How to distribute the config file? For now it's inside the package, shall we put it inside /etc/, /usr/local/share or some other path?

• The current config might as well be two environment variables - just sayin' ...

@sthagen: The config is mandatory. I guess it won't be only 2 options in there. Nevertheless, I don't say that it needs to be yaml...

@sustefil Early stages of the standard listed the following approach:

1. the corresponding argument from the command line,
2. the config file specified on the command line,
3. the corresponding environment variable,
4. the local configuration of the program,
5. the user configuration of the program or
6. the system configuration of the program.

If more than one of these value is present, the program should prefer the one with the lowest number in the list above.

This pretty much matches the approach @sthagen was suggesting. (4, 5, 6 reflect the *nix best practice of working from config files). So here is my suggestion:

1. the corresponding argument from the command line,
2. the config file specified on the command line,
3. the corresponding environment variable,
4. the local configuration of the program,
5. the user configuration of the program, (to say: the dot file in user home)
6. the system configuration of the program (which has the default values from the package).

I'm open to drop 3 and 4 from the list.

[tschmidtb51]

2) Usage through CLI command is now possible, shall it be also possible to use it as a python module? (e.g. import cvrf2csaf; cvrf2csaf.convert(...))

Short and simple: Yes. We also want to be able to use that programmatically. Background: There might be certain things / issues in the resulting CSAF which a vendor can easily fix programmatically and therefore wants to include the module in his own program.