Summary

Currently, each repo that uses the PTB defines it's own class Config. This can make it more difficult during PTB migrations to keep track of newly added, yet critical variables. Additionally, some aspects of PTB are hard-coded. It would be cumbersome to resolve all the potential issues, so we'll start by introducing a class BaseConfig which will require the python_versions to be specified (as an attribute or property). The minimum_python_version will be defined as a property with the value being the minimum of the supplied python_versions.

The BaseConfig class requested in this ticket should primarily apply to all projects but is not necessarily identical to the PTB's own configuration. In result we might have at least 3 different configurations

• BaseConfig class (provided by the PTB)
• PTB's own config, probably derived from the BaseConfig class
• the configuration of each of the other python repositories
  • derived from the BaseConfig class
  • potentially empty

Proposed validation

• Ensure correct data types
• Python version format: ignore
• Required attributes, not mentionend in the BaseConfig: not supported

Task(s)

• Consider / do a light prototype of the different class options
  • class with attributes, class with (abstract) properties, pydantic
• Write up findings in an ADR-like fashion & share for feedback
  • see Basics of Architecture Decision Records (ADR)
• Work on implementing the class in exasol/toolbox/nox/config.py
  • want to validate the python_versions are specified as expected (valid python versions)
  • want to include minimum_python_version property (comes from python_versions)
  • add a docstring to the previous attributes/properties indicating what these are used for
  • remove python_versions from the class Config
  • (method-dependent) create unit tests
  • add to documentation -> might be moved into another task
  • add to changelog with summary at top with instructions for downstream repos on how to update
  • ❌ ensure changes are carried through to the template -> won't do in this one as PTB should be released first. otherwise, new projects are referencing a feature that doesn't exist yet & the related CI integration tests will fail. will think about for another issue, but could modify the CI to handle this as we'd want to test that changes work with template prior to a release. however, care would need to be taken so that only tests are affected and not the saved template.