Merge `global_options` with `extra_options`
Currently, there are two ways to add custom fields to the needs schema:
- https://sphinx-needs.readthedocs.io/en/latest/configuration.html#needs-extra-options
- https://sphinx-needs.readthedocs.io/en/latest/configuration.html#needs-global-options
I feel having two ways
- makes it more confusing for the user
- makes the internal code more complex
I believe the features of the global options can essentially be merged into extra options and then deprecated:
- default; set a default value, if the field is not specified by the user
- filtered defaults; set a default value, if the field is not specified by the user, and the need passes a filter
This can be allowed by the new extra_option format #1338, e.g.
needs_extra_options = [
{
"name": "example",
"default": "my value",
"filtered_defaults": [
('closed', 'status.lower() in ["done", "resolved", "closed"]'),
]
}
]
I like the syntax.
But what about internal options, like style or layout?
Are they defined in needs_extra_options as well?
If yes, maybe we shall call the config-var then just needs_options to indicate that it cares about all forms of options, not only new/extra ones.
I mean it's a huge breaking change. So in the end, we can rename stuff as well.
Or maybe have needs_extra_options and needs_options in parallel for a while, to write deprecation warnings.
But what about internal options, like
styleorlayout?
yeh good point, I feel the problem is that global_options is conflating a few things that it can do:
- setting defaults for
extra_options, which I think is better co-located onextra_optionitems - setting defaults for
extra_links, which I think is better co-located onextra_linksitems - setting defaults for any internal field; this should at least be constrained to only fields where it makes sense (similar to #1387)
- defining completely new fields; which I don't think it should be allowed to do; that should only be done in
extra_options
Ideally I think needs_extra_options should be called needs_custom_fields and needs_global_options, if it is kept for internal fields, should be called needs_field_defaults.
this feels a lot more self-explanatory