✨ Add show_warning_types configuration variable
#12131
Conversation
|
I remember there is a related issue or at least a comment about it Had seen it yesterday so I'll try to find it again. |
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
found it |
|
LGTM! |
|
Ah @picnixz its not the end of the world, but I would ask in future you don't merge my PRs 😬 I'm very "encouraging" of having good commit messages, and I was about to commit this with most of #12131 (comment) as the message |
ah sorry! I just got the notification now for the ruff PR as well (since you replied with an emoji I thought it was fine) |
No worries! As I mentioned, I just like to make sure they have a good commit message |
This PR add the
show_warning_typesconfig variable which when set toTrue, prepends the type and subtype (if set) to warning messages.For example:
This follows the best practices of other tools, such as mypy and ruff to provide the user greater information on the warning:
To provide greater specificity for the origin of the warning, particularly for extensions which utilise warning types. Currently these extensions have to provide bespoke solutions for showing the warning origin (see e.g. https://myst-parser.readthedocs.io/en/latest/configuration.html#build-warnings)
To encourage users to deal with warnings. I strongly recommend for users to run
sphinx-build -nW --keep-going, then fix all warnings. Practically this is not always possible and so the use ofshow_warning_typesandsuppress_warnings, provides a way for users to deal with most warnings, whilst being able to suppress "less important" onesNote currently, the default is
False, i.e. they will still not be shown, which is done in order to introduce any breaking changes.But, like python/mypy#13542, I would strongly encourage this eventualy defaulting to
True.closes #8845