`objects.inv` is not generated deterministically when there are duplicate references about sphinx HOT 3 CLOSED

Quick comment: it's probably because of parallel read/merge and the fact that the files could possibly be discovered in a nondeterministic way. I can investigate this tomorrow.

from sphinx.

I can't reproduce this one, even with a somewhat smaller QEMU docs. I think the issue might comes from the fact that the QEMU docs has a lot of internal extensions and maybe some of the mess things up. Also, it appears that there is only one label in intersphinx being created for this driver title (you can inspect the inventory using python -m sphinx.ext.intersphinx FILE_OR_URL).

project.zip

For now, I'll close the issue until you find a MWE (otherwise this issue will likely be opened for years).

from sphinx.

A theory and a suggestion:

I think that a likely cause of this is variance in the order that source documentation files are read from the filesystem during Sphinx project build. That could explain why it's tricky to replicate on a single machine/filesystem -- because in isolation, that filesystem may return results in fairly-or-entirely deterministic order -- and also could mean that it's tricky to write a traditional unit test case for this, because uncovering the problem would be reliant on behaviour outside of the Sphinx codebase.

I'm wondering whether to commence work on a continuous integration test to attempt to smoke this out. If I did -- this is the suggestion part -- I'd probably begin by adding disorderfs to the GitHub Actions unit test workflows - disorderfs is a userspace-filesystem that can return filesystem results in randomized order, and is available as a Debian package.

from sphinx.