sphinx-needs icon indicating copy to clipboard operation
sphinx-needs copied to clipboard

Merge `global_options` with `extra_options`

Open chrisjsewell opened this issue 1 year ago • 2 comments

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

  1. makes it more confusing for the user
  2. 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"]'),
        ]
    }
]

chrisjsewell avatar Feb 24 '25 10:02 chrisjsewell

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.

danwos avatar Feb 24 '25 10:02 danwos

But what about internal options, like style or layout?

yeh good point, I feel the problem is that global_options is conflating a few things that it can do:

  1. setting defaults for extra_options, which I think is better co-located on extra_option items
  2. setting defaults for extra_links, which I think is better co-located on extra_links items
  3. setting defaults for any internal field; this should at least be constrained to only fields where it makes sense (similar to #1387)
  4. defining completely new fields; which I don't think it should be allowed to do; that should only be done inextra_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

chrisjsewell avatar Feb 24 '25 15:02 chrisjsewell