Boolean values passed to flag --define are wrongly interpreted as strings when building Sphinx docs

[bartvanb]

Describe the bug

I want to build Sphinx docs locally with --define autosummary_generate=0 to temporarily disable the autosummary extension. However, my value of 0 is not interpreted as boolean despite that the docs say I should provide 0 or 1 for booleans.

How to Reproduce

> sphinx-build docs docs/_build/html --define autosummary_generate=0
Running Sphinx v8.1.3
loading translations [en]... done
WARNING: The config value `autosummary_generate' has type `str'; expected `bool' or `list'.
loading pickled environment... The configuration has changed (1 option: 'pygments_dark_style')
done
WARNING: autosummary_generate: file not found: 0.rst

Note the WARNINGS: they show that sphinx-build does not interpret the 0 as I intended.

Relevant content conf.py:

extensions = [
    "sphinx.ext.autosummary",
]

autosummary_generate = True  # Turn on sphinx.ext.autosummary

[AA-Turner]

See also:

• config: Accept string values 0 and 1 for 'translation_progress_classes' option #13074 (comment) (most relevant prior discussion)
• Fix #8549: i18n: -D gettext_compact=0 is no longer working #8556
• Fix #6900: sphinx-build: Allow to pass boolean value via -D option #6908
• -D translation_progress_classes=0 doesn't convert to False as it should #13071
• config: Accept string values 0 and 1 for 'translation_progress_classes' option #13074

---

Extract from the thread in #13074:

From @timhoffm

Wouldn't it be better to coerce the type when processing the define parameter? By adding '0', '1' here, we (i) allow translation_progress_classes = '0' in conf.py, which seems unnecessarily permissive, and (ii) more importantly, every usage site has to check both truthy variants. - That's still okish in the present case, because there are only two usages, but it's not a pattern that scales for more heavily used parameters.

From me:

I think iff bool is a valid type for the config value, then 0 and 1 should be converted. I agree with Tim that this should ideally be done at the command-line-parsing stage, as we offer -D spam=0 as a shortcut to spam = False.

From @jayaddison (who's stepped back for the moment)

Ok, so to confirm: we'll extend the parsing of define options to check for corresponding config values, and for config values that contain either the bool type or an ENUM type that lists both bool values, we'll map the string values '0' and '1' to False and True respectively.

(maybe stating the somewhat-apparent-already, but just making sure -- the details about multiple types being possible for a config value, and also that ENUM can contain bool, are relevant here I think)

---

A