alembic / sphinx puzzler

[James Addison]

Hi folks,

I noticed what _seemed_ like a quick reproducible-build fix for alembic (a
database migration framework written in Python).  A few hours later though,
I'm still puzzled.

The problem appears in a similar pattern across various architectures in
the diffoscope results for alembic -- both amd64[1] and arm64[2], for
example.  It looks like the variations are in sphinx-generated
documentation where the ordering of collection elements -- like the items
in this attribute definition[3] -- differs in the output.

My understanding is that sphinx is using Python 3.11's built-in AST parser,
which doesn't provide parse-tree traversal order guarantees, during these
builds - and that'd seem to make sense as a cause.

Also: this might be the same issue as described in
'randomness_in_property_annotations_generated_by_sphinx'[4].

Does anyone have suggestions about how to proceed?  I'll likely take more
of a look again tomorrow.

Thanks,
James

(note: posting from my work email, because some of my work infrastructure
uses alembic, and so I think there's a clear, if small, work-related
motivation for this)

[1] -
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/alembic.html

[2] -
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/diffoscope-results/alembic.html

[3] -
https://github.com/sqlalchemy/alembic/blob/a968c9d2832173ee7d5dde50c7573f7b99424c38/alembic/ddl/impl.py#L90

[4] -
https://tests.reproducible-builds.org/debian/issues/unstable/randomness_in_property_annotations_generated_by_sphinx_issue.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20230214/735eba19/attachment.htm>