Skip to content

Making the config generator more robust to config option changes #2821

@terriko

Description

@terriko

@Rexbeast2 has done a nice job of giving us an initial config generator in the recently-merged #2699.

Right now, it relies on a pre-populated list of config options to fit into the text, and I'm a bit worried that we'll wind up with it going out of date as new config options are added or changed.

There's a few possible ways to handle this:

  1. Being really careful during code review to remind people to add new configs to the generator
  2. Scripts or linters to spit out some sort of warning if a config option is added and it's not in the generator
  3. Changing the config generator to iterate through all of our config options

Since I'm not particularly perfect about remembering things I don't think option 1 is viable long-term. I think option 3 is probably the best, maybe supplemented with options 1 & 2 to make sure any additional help text/description needed for the config file is added.

I'm not sure what the best way to handle this would be but here's some ideas:

  • Our config options are basically the same as our command-line options, so you should be able to iterate through those and print each one. I think they're all in ArgumentParser and start getting added here: https://github.com/intel/cve-bin-tool/blob/main/cve_bin_tool/cli.py#L96
  • They're already set up in groups and have help text but we might need different text to make more sense in a config file context. You'd have to sort of look through the current static configs and see if there's an elegant way to handle these. Maybe have config_generator maintain its own list of config help strings and add them with each, similar to what we're doing now but with a less static template?
  • Some options in the CLI may not make sense as config options (e.g. there's no --help in a config file and probably --version isn't a config you need either) so you might have to figure out how to drop those CLI flags when figuring the rest out.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions