@yuja I'm trying to find a compromise between our points of view : I'd like very much it to be run automatically (hence an integration test), and you want to be parametrizable. So, I'm pushing a version that has these two properties, working with env variables, since command-line arguments are already used by the testing framework. Hope it'll suit you, if it doesn't, I'll put it in examples and find a way to run it anyway

@yuja we don't need a seed to reproduce: failed examples contain all the information (that's a difference with the Python version)

@yuja now that 4.9 is out, I'm getting back to this.

@yuja the doc you're linking is about integration tests, so it wouldn't apply to these tests which are really unitary in my mind. Usually the main difference would be the access to the private constructs that the integration tests can't perform, but it's true that most of these implementations are public anyway.

@yuja I talked with @lothiraldan about this today. It turns out that it'd be better to provide a basesheads returning a set directly from the MissingAncestors object (I do have a Rust implementation for heads).

Given this conversation, and its outcome as materialised with latest versions of D5441 and D5442, we can now simply abandon this one.

@yuja this new version exports the LazyAncestors name to Python, expecting revlog.ancestors to do the right thing (as a factory then). I agree that the destiny of the older rustlazyancestors is to disappear, but I'd prefer to wait a bit before doing that
@kevincox I'd agree in principle, but since we only have one caller, whose role is precisely to abstract those differencies, we decided that we actually don't need to maintain that convention (and rustext can ne considered a foreign module, so that this is not really a breaking of the naming convention for new classes within hg)

@yuja about the lazy importer, and just to clarify: so you're saying it's not worth it to delay until rustext is actually used. I'm fine with that, will do it.
I didn't amend that patch yet, but you might have received notifications due to evolve of the whole stack.

Does the class name actually matter? Personally I don't care if
lazyancestors() function returns a LazyAncestors object. We'll anyway
need a wrapper function to make pure ancestors and rustext ancestors
compatible.

@yuja, thanks for the queueing !