Collect constants in central .yaml file

[hpoeche]

We have some constants that are used throughout the project, like the API base path, the metamodel version, the schema version tag and some more.
To reduce maintenance overhead and error risk, all constants that are version dependent, should be collected in a single .yaml file in the repository root and read from there on runtime.

[joalbalade]

Hello, I'm a newcomer and I would like to contribute. Is this issue still available?

[s-heppner]

Hi @joalbalade, thanks for wanting to contribute! This issue is still open, but might be a little hard for a new contributor that doesn't have the big picture yet. If you want to help, you could get started with #596 :)

[joalbalade]

Thanks @s-heppner, I will put an eye on it :)

[hpoeche]

Additionally, we should use this single point of truth to fix the used version of ruff (introduced in #601) and mypy.

[s-heppner]

As well as supported Python min and max version

[JAB1305]

After some consideration with the required features here, I would propose to instead have multiple .yaml files in different places.

• versions.yaml at the repo root
• server/config.yaml for server base path (and maybe more in the future)

The supported python version and dependency versions currently live in the modules' .toml files. These have no way to consume entries from an external config file. Instead I would suggest to create a central versions.yaml and extend the existing /etc/scripts/check_python_versions_coincide.py into a more general checker. Ideally it can verify any entry in the yaml against the 3 toml files. For future dependencies that would allow us to simply add an entry if we want it to be globally fixed.

Configuration entries that are currently "hidden" within the ci.yml should also live there (metamodel version, schema version tag) although maybe in a separate section. CI pipeline can then construct its ENV vars from the yaml.

Constants like the server base path should rather live in a separate config.yaml within the server package, which might be generally useful, and consumed by the module directly from there.

Would appreciate some thoughts on that approach.

[s-heppner]

I can see why it makes sense to have a server/config.yaml with the API base path to be shipped with and used by the modules of the server package.
Nevertheless, I think it makes sense to have one file a developer has to look in to know exactly where they're at w.r.t. the versions.

Therefore I propose a hybrid solution:

• Add the server.config.yaml with the API base path
• Also add it to /versions.yaml
• Expand (and possibly rename, or add another script) check_python_versions_coincide.py that checks that these two files have the same API base path.