since this is a part of #71601 , do you mind if i close all these smaller namespace pacakges and just track the issues in #71601

since this is a part of #71601 , do you mind if i close all these smaller namespace packages and just track the issues in #71601

whatever looks cleaner on git log - i reworked the commit messages for the individual PRs to fit the required format, so merging the individual PRs would be a bit more beautiful than doing it all in #71601

right, but none of them really have tests, but that's okay if sphinx exercises those code paths, its just that a series of fragmented PRs are a little harder to track, not to mention that they are all highly aligned to bumping sphinx

I deactivated the tests as they depend on sphinx. I'm pretty new to Nix, but in BitBake i would have made dependencies on the build stages on the packages (so sphinx would be built in between build of the sphinxcontrib-packages and test of the sphinxcontrib-packages). Any way to express this in Nix?

nix resolves the dependency graph into a direct-acyclic graph, so there's no way to have cycles. It's a known issue: #63168

you could technically do an override and pass whether or not you want the dependencies to test themselves, but AFAIK this is discouraged as you get a lot of one-off derivations

nix resolves the dependency graph into a direct-acyclic graph, so there's no way to have cycles. It's a known issue: #63168

Yes. That would need some way of snapshotting the derivations before running the tests, building sphinx and then running the tests from the snapshots. The derivations should not be influences by the test results. The important thing is that postponing the tests needs to be triggered by a nix expression so that the derivation does not change.

We should stop the off-topic discussions here.

superseded by #71601