[PATCH 00/57] docs: Add new QAPI transmogrifier

John Snow posted 57 patches 3 weeks, 6 days ago
There is a newer version of this series
docs/conf.py                           |  18 +-
docs/devel/codebase.rst                |   6 +-
docs/glossary.rst                      |  10 +-
docs/index.rst                         |   1 +
docs/qapi/index.rst                    |  53 ++
docs/sphinx-static/theme_overrides.css |  98 ++-
docs/sphinx/compat.py                  | 229 ++++++
docs/sphinx/qapi_domain.py             | 981 +++++++++++++++++++++++++
docs/sphinx/qapidoc.py                 | 948 +++++++++++++-----------
docs/sphinx/qapidoc_legacy.py          | 440 +++++++++++
scripts/qapi-lint.sh                   |  55 ++
scripts/qapi/backend.py                |   2 +
scripts/qapi/main.py                   |  10 +-
scripts/qapi/parser.py                 | 118 ++-
scripts/qapi/source.py                 |   4 +-
tests/qapi-schema/doc-good.out         |  10 +-
tests/qapi-schema/test-qapi.py         |   2 +-
17 files changed, 2498 insertions(+), 487 deletions(-)
create mode 100644 docs/qapi/index.rst
create mode 100644 docs/sphinx/compat.py
create mode 100644 docs/sphinx/qapi_domain.py
create mode 100644 docs/sphinx/qapidoc_legacy.py
create mode 100755 scripts/qapi-lint.sh
[PATCH 00/57] docs: Add new QAPI transmogrifier
Posted by John Snow 3 weeks, 6 days ago
Hi! This series is based on armbru/pull-qapi-2025-02-26.

This series is a "minimum viable" version of the new QAPI documentation
system. It does the bare minimum under the new framework, saving nice
features for later.

Patches 3-29 implement the qapi_domain extension.
Patches 30-57 implement the qapidoc "Transmogrifier".

This series is still "RFC" quality, though it's quite nearly actually
ready for inclusion. The "add transmogrifier test document" patch is not
intended for actual merge, it's just there to demonstrate the new
document generator by producing output in docs/manual/qapi/index.html.

Known shortcomings in this series:

- Still no new QAPI unit tests. I'll add those for next go-around.
- No new documentation. Also for next revision. I'll document the QAPI
  domain syntax and give a brief overview of how the transmogrifier
  functions, and a quick rundown of any new rST syntax that may be
  pertinent to QAPI documentation writers.
- IFCOND information is still rendered in two places, we'll need to
  decide where and how we want to render it.
- No QAPI namespace support ... yet. So we can't enable it for QMP, QGA
  and QSD simultaneously just yet. I don't think it will be difficult.

Unknown shortcomings in this series:

- ???

New stuff overall from the last iteration of this series:

- @foo is processed into ``foo`
- "The members of ..." messages have been temporarily re-added until we
  can smooth over the inliner.
- This series runs under Sphinx 3.4.3 to Sphinx 8.2.0 inclusive. It
  truly is a Christmas miracle. (please clap)
- This series now fully type checks and lint checks under Sphinx 8.2.0,
  but may not type check under earlier Sphinx versions. Achieving this
  alone, nevermind in conjunction with the above, was a literal
  herculean labor.

I really must stress again how frustratingly difficult it was to achieve
the prior two bullet points. I *do* in fact want a cookie and/or an
award ribbon.

--js

John Snow (57):
  do-not-merge
  qapi: shush pylint up
  docs/sphinx: create QAPI domain extension stub
  docs/sphinx: add compat.py module and nested_parse helper
  docs/qapi-domain: add qapi:module directive
  docs/qapi-domain: add QAPI domain object registry
  docs/qapi-domain: add QAPI index
  docs/qapi-domain: add resolve_any_xref()
  docs/qapi-domain: add QAPI xref roles
  docs/qapi-domain: add compatibility node classes
  docs/qapi-domain: add qapi:command directive
  docs/qapi-domain: add :since: directive option
  docs/qapi-domain: add "Arguments:" field lists
  docs/qapi-domain: add "Features:" field lists
  docs/qapi-domain: add "Errors:" field lists
  docs/qapi-domain: add "Returns:" field lists
  docs/qapi-domain: add qapi:enum directive
  docs/qapi-domain: add qapi:alternate directive
  docs/qapi-domain: add qapi:event directive
  docs/qapi-domain: add qapi:object directive
  docs/qapi-domain: add :deprecated: directive option
  docs/qapi-domain: add :unstable: directive option
  docs/qapi-domain: add :ifcond: directive option
  docs/qapi-domain: add warnings for malformed field lists
  docs/qapi-domain: add type cross-refs to field lists
  docs/qapi-domain: add CSS styling
  docs/qapi-domain: add XREF compatibility goop for Sphinx < 4.1
  docs/qapi-domain: warn when QAPI domain xrefs fail to resolve
  docs/qapi-domain: Fix error context reporting in Sphinx 5.x and 6.x
  qapi/parser: adjust info location for doc body section
  qapi: expand tags to all doc sections
  qapi/schema: add __repr__ to QAPIDoc.Section
  docs/qapidoc: add transmogrifier stub
  docs/qapidoc: split old implementation into qapidoc_legacy.py
  docs/qapidoc: Fix static typing on qapidoc.py
  do-not-merge
  docs/qapidoc: add transmogrifier class stub
  docs/qapidoc: add visit_module() method
  qapi/source: allow multi-line QAPISourceInfo advancing
  docs/qapidoc: add visit_freeform() method
  docs/qapidoc: add preamble() method
  docs/qapidoc: add visit_paragraph() method
  docs/qapidoc: add visit_errors() method
  docs/qapidoc: add format_type() method
  docs/qapidoc: add add_field() and generate_field() helper methods
  docs/qapidoc: add visit_feature() method
  docs/qapidoc: prepare to record entity being transmogrified
  docs/qapidoc: add visit_returns() method
  docs/qapidoc: add visit_member() method
  docs/qapidoc: add visit_sections() method
  docs/qapidoc: add visit_entity()
  docs/qapidoc: implement transmogrify() method
  docs: disambiguate cross-references
  docs/qapidoc: add transmogrifier test document
  docs/qapidoc: process @foo into ``foo``
  docs/qapidoc: add intermediate output debugger
  docs/qapidoc: Add "the members of" pointers

 docs/conf.py                           |  18 +-
 docs/devel/codebase.rst                |   6 +-
 docs/glossary.rst                      |  10 +-
 docs/index.rst                         |   1 +
 docs/qapi/index.rst                    |  53 ++
 docs/sphinx-static/theme_overrides.css |  98 ++-
 docs/sphinx/compat.py                  | 229 ++++++
 docs/sphinx/qapi_domain.py             | 981 +++++++++++++++++++++++++
 docs/sphinx/qapidoc.py                 | 948 +++++++++++++-----------
 docs/sphinx/qapidoc_legacy.py          | 440 +++++++++++
 scripts/qapi-lint.sh                   |  55 ++
 scripts/qapi/backend.py                |   2 +
 scripts/qapi/main.py                   |  10 +-
 scripts/qapi/parser.py                 | 118 ++-
 scripts/qapi/source.py                 |   4 +-
 tests/qapi-schema/doc-good.out         |  10 +-
 tests/qapi-schema/test-qapi.py         |   2 +-
 17 files changed, 2498 insertions(+), 487 deletions(-)
 create mode 100644 docs/qapi/index.rst
 create mode 100644 docs/sphinx/compat.py
 create mode 100644 docs/sphinx/qapi_domain.py
 create mode 100644 docs/sphinx/qapidoc_legacy.py
 create mode 100755 scripts/qapi-lint.sh

-- 
2.48.1

Re: [PATCH 00/57] docs: Add new QAPI transmogrifier
Posted by Markus Armbruster 3 weeks, 4 days ago
When I eyeballed the previous iteration, I made a few observations[1].
Let's see what has changed.

} New table of contents shows one level, old two.  No objection; the
} navigation thingie on the left is more useful anyway.

No change.  Okay.

} The new generator elides unreferenced types.  Generally good, but two
} observations:
} 
} * QapiErrorClass is unreferenced, but its members are mentioned in
}   Errors sections.  QapiErrorClass serves as better than nothing error
}   code documentation, but it's gone in the new doc.  So this is a minor
}   regression.  We can figure out what to do about it later.
} 
} * Section "QMP errors" is empty in the new doc, because its entire
}   contents is elided.  I guess we should elide the section as well, but
}   it's fine to leave that for later.

Unreferenced types are back.  Okay; we can elide them later.

} Old doc shows a definition's since information like any other section.
} New doc has it in the heading box.  Looks prettier and uses much less
} space.  Not sure the heading box is the best place, but it'll do for
} now, we can always move it around later.

No change.

} The new doc's headings use "Struct" or "Union" where the old one uses
} just "Object".  Let's keep "Object", please.

Fixed.

} In the new doc, some member references are no longer rendered as such,
} e.g. @on-source-error and @on-target-error in BackupCommon's note.
} Another small regression.

Fixed.

} Union branches are busted in the new generator's output.  I know they
} used to work, so I'm not worried about it.

Fixed: "When TAG-MEMBER is VALUE; The members of BRANCH-TYPE."

The semicolon feels odd.  I'd use a colon there.  Or put the when at the
end like the old generator does: "The members of BRANCH-TYPE when
TAG-MEMBER is VALUE".

Side effects, I think:

* Members of explicit base types are no longer inlined.  Instead: "The
  members of BASE-TYPE."

* Members of explicit command / event argument types are no longer
  inlined.  Instead: "The members of ARG-TYPE."

Both fine for the initial version.

} The new doc shows the return type, the old doc doesn't.  Showing it is
} definitely an improvement, but we need to adjust the doc text to avoid
} silliness like "Returns: SnapshotInfo – SnapshotInfo".

No change.  Can polish on top.

} The new doc shows Arguments / Members, Returns, and Errors in two-column
} format.  Looks nice.  But for some reason, the two columns don't align
} horizontally for Errors like they do for the others.  Certainly not a
} blocker of anything, but we should try to fix it at some point.

No change.  Fine to leave for later.

} The new doc doesn't show non-definition conditionals, as mentioned in
} the cover letter.  It shows definition conditionals twice.  Once should
} suffice.

No change.  You asked for advice, and I gave some[2].

} There's probably more, but this is it for now.

Again, this is it for now.



[1] Message-ID: <87wmds4tpk.fsf@pond.sub.org>
https://lore.kernel.org/qemu-devel/87wmds4tpk.fsf@pond.sub.org/

[2] Message-ID: <87zfhya0is.fsf@pond.sub.org>
https://lore.kernel.org/qemu-devel/87zfhya0is.fsf@pond.sub.org/
Re: [PATCH 00/57] docs: Add new QAPI transmogrifier
Posted by John Snow 3 weeks, 4 days ago
On Thu, Mar 6, 2025, 7:35 AM Markus Armbruster <armbru@redhat.com> wrote:

> When I eyeballed the previous iteration, I made a few observations[1].
> Let's see what has changed.
>
> } New table of contents shows one level, old two.  No objection; the
> } navigation thingie on the left is more useful anyway.
>
> No change.  Okay.
>

This is configured in the .rst file, not in code. I just happened to use a
different level in my test document.

For initial merge, I'll probably enable the new generator on QMP only while
I work on namespace support.


> } The new generator elides unreferenced types.  Generally good, but two
> } observations:
> }
> } * QapiErrorClass is unreferenced, but its members are mentioned in
> }   Errors sections.  QapiErrorClass serves as better than nothing error
> }   code documentation, but it's gone in the new doc.  So this is a minor
> }   regression.  We can figure out what to do about it later.
> }
> } * Section "QMP errors" is empty in the new doc, because its entire
> }   contents is elided.  I guess we should elide the section as well, but
> }   it's fine to leave that for later.
>
> Unreferenced types are back.  Okay; we can elide them later.
>

Yep, it will come along with the inliner later.


> } Old doc shows a definition's since information like any other section.
> } New doc has it in the heading box.  Looks prettier and uses much less
> } space.  Not sure the heading box is the best place, but it'll do for
> } now, we can always move it around later.
>
> No change.
>

Always happy to take HTML/CSS patches from someone with a strong opinion.
For now, though, ...


> } The new doc's headings use "Struct" or "Union" where the old one uses
> } just "Object".  Let's keep "Object", please.
>
> Fixed.
>
> } In the new doc, some member references are no longer rendered as such,
> } e.g. @on-source-error and @on-target-error in BackupCommon's note.
> } Another small regression.
>
> Fixed.
>
> } Union branches are busted in the new generator's output.  I know they
> } used to work, so I'm not worried about it.
>
> Fixed: "When TAG-MEMBER is VALUE; The members of BRANCH-TYPE."
>
> The semicolon feels odd.  I'd use a colon there.  Or put the when at the
> end like the old generator does: "The members of BRANCH-TYPE when
> TAG-MEMBER is VALUE".
>

Easy to change!


> Side effects, I think:
>
> * Members of explicit base types are no longer inlined.  Instead: "The
>   members of BASE-TYPE."
>
> * Members of explicit command / event argument types are no longer
>   inlined.  Instead: "The members of ARG-TYPE."
>
> Both fine for the initial version.
>

Yeah, inliner is all or nothing.


> } The new doc shows the return type, the old doc doesn't.  Showing it is
> } definitely an improvement, but we need to adjust the doc text to avoid
> } silliness like "Returns: SnapshotInfo – SnapshotInfo".
>
> No change.  Can polish on top.
>

I have a patch for this in my kvm forum branch, along with "convert
everything into actual cross-references". Will send afterwards.


> } The new doc shows Arguments / Members, Returns, and Errors in two-column
> } format.  Looks nice.  But for some reason, the two columns don't align
> } horizontally for Errors like they do for the others.  Certainly not a
> } blocker of anything, but we should try to fix it at some point.
>
> No change.  Fine to leave for later.
>

Yes, but I did figure out why and I do have a solution planned now. It's
something I had to work around for "The members of..." pointers.


> } The new doc doesn't show non-definition conditionals, as mentioned in
> } the cover letter.  It shows definition conditionals twice.  Once should
> } suffice.
>
> No change.  You asked for advice, and I gave some[2].
>

D'oh!


> } There's probably more, but this is it for now.
>
> Again, this is it for now.
>
>
>
> [1] Message-ID: <87wmds4tpk.fsf@pond.sub.org>
> https://lore.kernel.org/qemu-devel/87wmds4tpk.fsf@pond.sub.org/
>
> [2] Message-ID: <87zfhya0is.fsf@pond.sub.org>
> https://lore.kernel.org/qemu-devel/87zfhya0is.fsf@pond.sub.org/
>
>
Re: [PATCH 00/57] docs: Add new QAPI transmogrifier
Posted by Markus Armbruster 3 weeks, 5 days ago
John Snow <jsnow@redhat.com> writes:

> Hi! This series is based on armbru/pull-qapi-2025-02-26.
>
> This series is a "minimum viable" version of the new QAPI documentation
> system. It does the bare minimum under the new framework, saving nice
> features for later.

Not saved for later: a massive improvement of the generated
documentation's looks and usability.  Moreover, I hope the new generator
will be easier to maintain than the old one, because its inner workings
are closer to how Sphinx expects such things to work.  Fair?

>
> Patches 3-29 implement the qapi_domain extension.
> Patches 30-57 implement the qapidoc "Transmogrifier".
>
> This series is still "RFC" quality, though it's quite nearly actually
> ready for inclusion. The "add transmogrifier test document" patch is not
> intended for actual merge, it's just there to demonstrate the new
> document generator by producing output in docs/manual/qapi/index.html.
>
> Known shortcomings in this series:
>
> - Still no new QAPI unit tests. I'll add those for next go-around.

Not a blocker as far as I'm concerned, because I feel you're unlikely to
run away from this :)

> - No new documentation. Also for next revision. I'll document the QAPI
>   domain syntax and give a brief overview of how the transmogrifier
>   functions, and a quick rundown of any new rST syntax that may be
>   pertinent to QAPI documentation writers.

Likewise.

> - IFCOND information is still rendered in two places, we'll need to
>   decide where and how we want to render it.

I'll have a look, and then we'll talk.

> - No QAPI namespace support ... yet. So we can't enable it for QMP, QGA
>   and QSD simultaneously just yet. I don't think it will be difficult.
>
> Unknown shortcomings in this series:
>
> - ???

I'll try to find some, but I'm not overly optimistic ;)

> New stuff overall from the last iteration of this series:
>
> - @foo is processed into ``foo`
> - "The members of ..." messages have been temporarily re-added until we
>   can smooth over the inliner.
> - This series runs under Sphinx 3.4.3 to Sphinx 8.2.0 inclusive. It
>   truly is a Christmas miracle. (please clap)

*clap* clap* clap*

This is waaaay harder than it has any right to be.

> - This series now fully type checks and lint checks under Sphinx 8.2.0,
>   but may not type check under earlier Sphinx versions. Achieving this
>   alone, nevermind in conjunction with the above, was a literal
>   herculean labor.

scripts/qapi/ remains clean for me.  docs/sphinx/ improves from no type
checking to type checking with a version newer than the one I have on my
development box right now, which I count as an improvement.

> I really must stress again how frustratingly difficult it was to achieve
> the prior two bullet points. I *do* in fact want a cookie and/or an
> award ribbon.

We owe you an entire layer cake, with a marzipan figurine of your
conquering self on top.  Seriously, I could not have done this.
Re: [PATCH 00/57] docs: Add new QAPI transmogrifier
Posted by Markus Armbruster 3 weeks, 4 days ago
Markus Armbruster <armbru@redhat.com> writes:

> John Snow <jsnow@redhat.com> writes:
>
>> Hi! This series is based on armbru/pull-qapi-2025-02-26.
>>
>> This series is a "minimum viable" version of the new QAPI documentation
>> system. It does the bare minimum under the new framework, saving nice
>> features for later.
>
> Not saved for later: a massive improvement of the generated
> documentation's looks and usability.  Moreover, I hope the new generator
> will be easier to maintain than the old one, because its inner workings
> are closer to how Sphinx expects such things to work.  Fair?
>
>>
>> Patches 3-29 implement the qapi_domain extension.
>> Patches 30-57 implement the qapidoc "Transmogrifier".
>>
>> This series is still "RFC" quality, though it's quite nearly actually
>> ready for inclusion. The "add transmogrifier test document" patch is not
>> intended for actual merge, it's just there to demonstrate the new
>> document generator by producing output in docs/manual/qapi/index.html.
>>
>> Known shortcomings in this series:
>>
>> - Still no new QAPI unit tests. I'll add those for next go-around.
>
> Not a blocker as far as I'm concerned, because I feel you're unlikely to
> run away from this :)
>
>> - No new documentation. Also for next revision. I'll document the QAPI
>>   domain syntax and give a brief overview of how the transmogrifier
>>   functions, and a quick rundown of any new rST syntax that may be
>>   pertinent to QAPI documentation writers.
>
> Likewise.
>
>> - IFCOND information is still rendered in two places, we'll need to
>>   decide where and how we want to render it.
>
> I'll have a look, and then we'll talk.

Two shortcomings, actually:

  - IFCOND in definitions (enum, struct, union, alternate, command,
    event) are rendered in two places.

    Example: query-tpm has 'if': 'CONFIG_TPM'.  The rendered
    documentation looks like this:

        Command query-tpm ["#if" "CONFIG_TPM"] (Since: 1.5)
            *Availability*: "CONFIG_TPM"

           Return information about the TPM device

           Example::
              [...]

    With the old generator, it looks like

        "query-tpm" (Command)
        ---------------------

        Return information about the TPM device


        Since
        ~~~~~

        1.5

        Example::
           [...]

        If
        ~~

        "CONFIG_TPM"

    So, three ways to present the information, none of them immediately
    obvious to a casual reader.  The easiest to guess right is perhaps
    the "Availability" box.

    The two new ways are in more conspicious spots than the old one is.
    Not sure I like that; I believe ifconds are fairly uninteresting to
    users of QMP most of the time.  More on that below.

    The "Availability" box is even more conspicious than the [#if ...]
    bracket.  It also uses more space.

    For complex conditions, the [#if ...] bracket can make the first
    line less readable.  Example:

        Command query-cpu-definitions ["#if" "TARGET_PPC or TARGET_ARM or TARGET_I386 or TARGET_S390X or TARGET_MIPS or TARGET_LOONGARCH64 or TARGET_RISCV"] (Since: 1.2)
            *Availability*: "TARGET_PPC or TARGET_ARM or TARGET_I386 or
           TARGET_S390X or TARGET_MIPS or TARGET_LOONGARCH64 or TARGET_RISCV"

           Return a list of supported virtual CPU definitions

    The first line matters.  This tips the balance for me.  Let's go
    with the "Availability" box at least for now.

    There's a symbol before "Availability" in the generated HTML.  Its
    meaning is less than obvious.  I remember you explained it to me,
    but I forgot.  We can polish this later.

  - IFCOND elsewhere is not rendered at all.  This is a regression.  The
    old generator shows it like this:

        "mptcp": "boolean" (optional) (**If: **"HAVE_IPPROTO_MPTCP")
           enable multi-path TCP.  (Since 6.1)

    I believe the regression is tolerable for now, because the
    information lost is only modestly useful for users of QMP, and the
    massive improvements the new generator provides outweigh this small
    loss.

    Why only modestly useful?  It tells the reader the thing's
    availability depends on how QEMU was built.  It also provides a clue
    that should let a developer or sufficiently clever non-developer
    rebuild QEMU to provide the thing.  This would involve some code
    spelunking.

>> - No QAPI namespace support ... yet. So we can't enable it for QMP, QGA
>>   and QSD simultaneously just yet. I don't think it will be difficult.

[...]
Re: [PATCH 00/57] docs: Add new QAPI transmogrifier
Posted by John Snow 3 weeks, 5 days ago
On Wed, Mar 5, 2025, 6:31 AM Markus Armbruster <armbru@redhat.com> wrote:

> John Snow <jsnow@redhat.com> writes:
>
> > Hi! This series is based on armbru/pull-qapi-2025-02-26.
> >
> > This series is a "minimum viable" version of the new QAPI documentation
> > system. It does the bare minimum under the new framework, saving nice
> > features for later.
>
> Not saved for later: a massive improvement of the generated
> documentation's looks and usability.  Moreover, I hope the new generator
> will be easier to maintain than the old one, because its inner workings
> are closer to how Sphinx expects such things to work.  Fair?
>

I hope so too, though some of the sphinx version compatibility hacks are
possibly fairly porcelain. The most egregious of them are for versions
prior to Sphinx 4.1.

Almost all of the compatibility hacks are factored into compat.py and they
are all documented with what versions they're there for. Most of the
ugliest is pre-4.1.


> >
> > Patches 3-29 implement the qapi_domain extension.
> > Patches 30-57 implement the qapidoc "Transmogrifier".
> >
> > This series is still "RFC" quality, though it's quite nearly actually
> > ready for inclusion. The "add transmogrifier test document" patch is not
> > intended for actual merge, it's just there to demonstrate the new
> > document generator by producing output in docs/manual/qapi/index.html.
> >
> > Known shortcomings in this series:
> >
> > - Still no new QAPI unit tests. I'll add those for next go-around.
>
> Not a blocker as far as I'm concerned, because I feel you're unlikely to
> run away from this :)
>

😅


> > - No new documentation. Also for next revision. I'll document the QAPI
> >   domain syntax and give a brief overview of how the transmogrifier
> >   functions, and a quick rundown of any new rST syntax that may be
> >   pertinent to QAPI documentation writers.
>
> Likewise.
>
> > - IFCOND information is still rendered in two places, we'll need to
> >   decide where and how we want to render it.
>
> I'll have a look, and then we'll talk.
>
> > - No QAPI namespace support ... yet. So we can't enable it for QMP, QGA
> >   and QSD simultaneously just yet. I don't think it will be difficult.
> >
> > Unknown shortcomings in this series:
> >
> > - ???
>
> I'll try to find some, but I'm not overly optimistic ;)
>

Missing documentation for undocumented members. You found one! :)


> > New stuff overall from the last iteration of this series:
> >
> > - @foo is processed into ``foo`
> > - "The members of ..." messages have been temporarily re-added until we
> >   can smooth over the inliner.
> > - This series runs under Sphinx 3.4.3 to Sphinx 8.2.0 inclusive. It
> >   truly is a Christmas miracle. (please clap)
>
> *clap* clap* clap*
>
> This is waaaay harder than it has any right to be.
>
> > - This series now fully type checks and lint checks under Sphinx 8.2.0,
> >   but may not type check under earlier Sphinx versions. Achieving this
> >   alone, nevermind in conjunction with the above, was a literal
> >   herculean labor.
>
> scripts/qapi/ remains clean for me.  docs/sphinx/ improves from no type
> checking to type checking with a version newer than the one I have on my
> development box right now, which I count as an improvement.
>
> > I really must stress again how frustratingly difficult it was to achieve
> > the prior two bullet points. I *do* in fact want a cookie and/or an
> > award ribbon.
>
> We owe you an entire layer cake, with a marzipan figurine of your
> conquering self on top.  Seriously, I could not have done this.
>

It's the stuff in compat.py that was the absolute hardest. You need that
stuff for this to work on the version ranges it works for, but typing it
was an extra special torture.

>
Re: [PATCH 00/57] docs: Add new QAPI transmogrifier
Posted by Markus Armbruster 3 weeks, 5 days ago
John Snow <jsnow@redhat.com> writes:

> On Wed, Mar 5, 2025, 6:31 AM Markus Armbruster <armbru@redhat.com> wrote:
>
>> John Snow <jsnow@redhat.com> writes:
>>
>> > Hi! This series is based on armbru/pull-qapi-2025-02-26.
>> >
>> > This series is a "minimum viable" version of the new QAPI documentation
>> > system. It does the bare minimum under the new framework, saving nice
>> > features for later.
>>
>> Not saved for later: a massive improvement of the generated
>> documentation's looks and usability.  Moreover, I hope the new generator
>> will be easier to maintain than the old one, because its inner workings
>> are closer to how Sphinx expects such things to work.  Fair?
>>
>
> I hope so too, though some of the sphinx version compatibility hacks are
> possibly fairly porcelain. The most egregious of them are for versions
> prior to Sphinx 4.1.
>
> Almost all of the compatibility hacks are factored into compat.py and they
> are all documented with what versions they're there for. Most of the
> ugliest is pre-4.1.

[...]

> It's the stuff in compat.py that was the absolute hardest. You need that
> stuff for this to work on the version ranges it works for, but typing it
> was an extra special torture.

Supporting such a wide range of versions is *expensive*.

Writing compat.py is sunk cost.

Maintaining it is not.  It's fragile hacks, hard to understand even with
deep Sphinx innards expertise, impossible to understand without.  I
figure if we somehow lost your expertise, we'd likely have to drop
support for old Sphinx the moment compat.py breaks.

Just because we can solve certain hard problems doesn't mean we should.
I question the wisdom of supporting such a wide range of Sphinx
versions.
Re: [PATCH 00/57] docs: Add new QAPI transmogrifier
Posted by Markus Armbruster 3 weeks, 3 days ago
This looks really, really close.  I like how you split the work into
patches, and your commit messages have been quite useful.  Thanks!