[jayaddison]

Purpose

This is a continuation of @adamtheturtle's pull request #14673; both changesets have been opened with the intent to provide compatibility with docutils v1.0-dev (in development).

This branch includes support for two suffix formats for RFC URLs in the unit test expectations: either the existing .html suffix, or a trailing forward-slash format adopted in docutils 1.0-dev.

References

• Continuation of Support Docutils 1.0 doctests and table widths #14673.

AI Disclosure

@adamtheturtle

AI disclosure: OpenAI Codex generated the changes and description, ran checks, and submitted this PR at the owner's request; no human review is claimed.

@jayaddison

No AI tools used

Edit: include AI disclosures per-author

[jayaddison]

@picnixz this should resolve the docutils-1.0-dev related test issues (at least, up to the time-of-writing)

[Darlokt]

Hej @jayaddison ,

As mentioned in #14611 (comment), these changes make the CI pass, but I don't think they fully address the underlying compatibility issues.

The RFC test changes appear to codify Sphinx's current dependency on Inliner.rfc_url, making generated RFC URLs intentionally vary with the Docutils version. Since the RFC Editor /info/rfcNNNN/ URL is now the canonical target and Sphinx can construct that URL itself (#14689), it seems preferable to make the :rfc: role output deterministic rather than teach the tests to accept both Docutils URL templates.

The doctest changes appear to handle only the places where the new Docutils representation currently causes failures. Native doctests are now represented as literal_block nodes with the code, pycon, and doctest classes, but Sphinx also relies on the old doctest_block type for other behavior, such as moving indented doctests out of block quotes and handling gettext_additional_targets = ['doctest-block']. Since these are different representations of the same semantic construct, it seems preferable to handle that distinction consistently across Sphinx rather than update only the execution and highlighting paths (#14681).

The table-width changes similarly make the immediate failures pass by converting colwidth values at the individual writer call sites. Since Docutils 1.0 changes the representation from integers to numeric strings, it seems preferable to treat that as a compatibility boundary and handle the supported representations consistently across the text, LaTeX, and Texinfo writers, with focused regression coverage (#14681), also keeping in mind the planned Docutils 2.0 changes in the future.

Also there are issues open for these changes to keep them tracked under, #14659 (RFC changes) and #14680 (Docutils table changes) respectively.

All the best!

Disclaimer, I wrote #14681 and #14689.

[jayaddison]

Ok; I've upvoted #14659, because as mentioned there, the IETF have begun referencing rfc-editor.org as canonical (using rel=canonical HTML attributes in RFC hyperlinks from datatracker.ietf.org).

I don't think that's required for docutils 1.0 compatibility, though; it shouldn't be a blocker.

[jayaddison]

Superseded by d19cbb5 (I think!)