Config story has been already described in detail for user and system scenarios covering L2 metadata.

Proposing for 2.0 as discussed on today's hacking session.

This is blocking #813.

Is this still free? It can be nice to play around and try to implement:
#38

Yes, this is free. I expect the configuration format will need some discussion though.

@therazix, regarding the implementation I would recommend to start with simplifying the following code:

Instead of the complex checking of the types and values, the code above should probably just do something like:

issue_trackers = tmt.utils.Config().get("/link/issue-trackers")

or maybe even something like this?

issue_trackers = tmt.utils.Config().link.issue-trackers

The rest would be handled by the Config class. @happz might also have some hints about how the implementation could look like.

@LecrisUT Cc ^^ would you have any tips WRT implementation of "containers with configuration"? In the light of current code in tmt.utils, the moved one in tmt.container, and possibly the future with attrs & co., how can we make configuration easier to use for developers, with guarantees of types and stuff like that?

It would be the best if we could, cheaply and easily, if possible, land on a state where the user would be notified if /link/issue-trackes is not a list of expected structures, and where the developer wouldn't need to worry about whether isinstance(/link/issue-trackers, list) and so on. Right now, with fmf id and raw config, we need to use the validation layer and then have _RawFoo typed dicts that get converted into actual data classes we define. Something more dynamic, but with the same guarantees and visibility for linters and IDEs would be very nice to have.

Configuration is very similar to any other fmf tmt consumes - we can definitely use what we have now, and improve everything later, but, maybe we could use the configuration as a prototyping ground for the better state of the future.

If I read this correctly the goal is for the user configurations to override the contents of the fmf file effectively? There is an ambiguity of how to order the preference between:

• default value (no field in the project's fmf)
• user config fmf
• project's fmf field specified

Maybe if we put some more restrictions that the user config can only affect leaf configurations the intent could be clearer. But then it can get quite weird figuring out which user config applies to the fmf tree of which project. Or are the fmf fields defined in the user configuration completely orthogonal, in which case what would the path signify? Are only a few fields or containers meant to be linked with configurations, maybe the class definition can be changed to a decorator instead of inheritance?

About the container part, it would depend on the part above, but generally I was thinking that the containers are just the datastructures and basically as close to a json-schema as possible. The reading of the source: fmf tree, click arguments or configuration could be completely separate from this. How to unify the definitions within the field would be a bit more tricky because that one is getting quite dense in the amount of arguments that are being passed, if only you could decorate those 😮‍💨. Well there is a way I guess that attrs is using by wrapping dummy functions ¹, but that would get verbose quite quickly.

If I read this correctly the goal is for the user configurations to override the contents of the fmf file effectively? There is an ambiguity of how to order the preference between...

I see, the original story describing/brainstorming the possible features can be confusing. I think we would like to start small first. Without handling user versus system configuration and without interaction with test or plan metadata.

We have the following tangible use case for the tmt link command: An fmf node /link saved under the ~/.config/tmt tree intended for storing supported issue trackers. The config can look like this:

issue-tracker:
  - type: jira
    url: https://issues.redhat.com
    tmt-web-url: http://tmt.testing-farm.io/
    token: <secret>

This is in no way related to affecting default values of tests or plans. It's a config to be used solely by the tmt link command. So, as the first step, here we would like to validate that it has the expected format and store the values in easily accessible objects.