You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Before the recent refactoring of the osc.conf module (#1387), I used oscrc to configure my plugin command. It worked ad-hoc, since the configuration was just a dictionary obtained from the config parser, and no validation/checking was performed.
Now it is unclear if this is still wanted/supported, but I feel like it is preferable to allow this, as a separate config file requires me to roll my own config parser and so on, and all the nice new machinery that is now in osc would have to be somewhat duplicated.
Describe the solution you'd like
The mechanics to define a new command could allow also giving config Fields.
Describe alternatives you've considered
What works now already but is monkeypatching level of hacky:
class MyOptions(osc.conf.Options):
new_field: str = Field(...)
osc.conf.Options = MyOptions
@birkenfeld I've just implemented and merged #1438
It allows using Options and HostOptions as a dicts with arbitrary values, loading values from oscrc works as well.
It is good enough to fix compatibility issues I introduced a while back, but I don't think we should use this as the final solution. Let's keep this open and try to come up with something better.
Is your feature request related to a problem? Please describe.
Before the recent refactoring of the
osc.conf
module (#1387), I usedoscrc
to configure my plugin command. It worked ad-hoc, since the configuration was just a dictionary obtained from the config parser, and no validation/checking was performed.Now it is unclear if this is still wanted/supported, but I feel like it is preferable to allow this, as a separate config file requires me to roll my own config parser and so on, and all the nice new machinery that is now in osc would have to be somewhat duplicated.
Describe the solution you'd like
The mechanics to define a new command could allow also giving config
Field
s.Describe alternatives you've considered
What works now already but is monkeypatching level of hacky:
Additional context
cc @dmach
The text was updated successfully, but these errors were encountered: