On 2023-05-24 19:40:56 +0200 (+0200), Agathe Porte wrote: [...] > Maybe the idea was to introduce %OLD_RELEASE_NAME% and to call sed to > replace this kind of strings in a build step, and not rely on sphinx > substitution at all. > > I know that I have done this a few times and it works fine as a very > simple preprocessor.
Similar things can be done at sphinx-build time with a custom Sphinx extension (can be a trivial Python module). We do that for the published security advisories list upstream in OpenStack: https://opendev.org/openstack/ossa/src/commit/136b24c/doc/source/conf.py#L31 https://opendev.org/openstack/ossa/src/commit/136b24c/doc/source/_exts/vmt.py That's a more complex example because we generate a ton of content out of structured data (YAML) files by splatting the relevant fields into substitutions in a Jinja2 template, but for basic string substitution you could get away with something far simpler, or even use a canned one like (this was simply my first web search result): https://pypi.org/project/Sphinx-Substitution-Extensions/ The examples in its readme look to be along the lines of the Debian Release Notes use case anyway. There's also basic substitutions support in the reStructuredText specification, which might be useful to reduce the amount of actual content you need to swap at build time: https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#substitution-definitions -- Jeremy Stanley
signature.asc
Description: PGP signature
