alembic / sphinx puzzler

[James Addison]

Hey Chris,

On Wed, Feb 15, 2023 at 7:27 PM Chris Lamb <chris at reproducible-builds.org>
wrote:

> This change to Sphinx makes alembic reproducible:
>
>
> https://github.com/lamby/sphinx/commit/4ad7670c1df00f82e758aaa8a7b9aaea83b8eaba
>
> Does this patch work for you?
>

Yes!  Thank you - that's a much better patch than an alternative approach I
was working on that attempted to sort the string-typed results of
processing the AST.  It produces stable results for me when I vary the
order of the set-within-a-tuple's elements in the input.

I'll file a bug on sphinx's GitHub repository about the original issue
within the next few hours.


> Why it hasn't been a problem before is rather curious to me, though.
> It may be just that it hasn't come up, but it may be because this
> value ultimately comes from a Python typing annotation. Yet at that
> point in the code, there doesn't seem to be anything special
> whatsoever about this tuple & set: it's really just a regular tuple
> and set.
>

 Could it be that other Sphinx documentation-generation issues tend to have
occluded this one?

I also have to admit that I still don't understand what it is that varies
(and frequently varies, apparently) across builds that exposed the problem
in the first place.  I'm not convinced that it's likely to be related to
the memory addresses of the datastructures.. I had a vague theory that
perhaps filesystem choice/layout could be a cause (perhaps a strange theory
at first: my rationale would be that it could cause the AST to read and
process files in a different order, and that that could affect the parser's
state in subtle ways.  I haven't even convinced myself of that possibility
entirely yet though).

Thanks again,
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20230216/5f3c14ad/attachment.htm>