For somer configs, it makes sense to have a global config override or default, that is, the value priority at read would be:
- any config value that is manually set via
get_config
- any config value that is set in a global config (to be designed)
- the defaults from the MRO
How exactly a global config mechanism should look like is not clear, but it could simple be a set_config function?
What may be problematic is that users may want to set configs globally, but only for a certain object type, e.g., forecasters in sktime, regressors in skpro, etc, so it is also a question whether there should be a super-global config in scikit-base, or whether each package should have its global config; and even if the latter, how we manage global configs for types of objects.
@RNKuhns has made a first draft in #149 a very long time ago. I think it is a great start but it does not meet the above requirements exactly, yet.
FYI @joshdunnlime.
For somer configs, it makes sense to have a global config override or default, that is, the value priority at read would be:
get_configHow exactly a global config mechanism should look like is not clear, but it could simple be a
set_configfunction?What may be problematic is that users may want to set configs globally, but only for a certain object type, e.g., forecasters in
sktime, regressors inskpro, etc, so it is also a question whether there should be a super-global config inscikit-base, or whether each package should have its global config; and even if the latter, how we manage global configs for types of objects.@RNKuhns has made a first draft in #149 a very long time ago. I think it is a great start but it does not meet the above requirements exactly, yet.
FYI @joshdunnlime.