Hi, more comments/requests/grunts :-)

fix commit message

besides a missing why paragraph in the commit message, lgtm

could you explain why you do this in your commit message? I have no opinion on whether one version is objectively better than the other, but you may have a reason for doing it :-)

looks overall good to me (see my comments), not sure I'm 100% confident there are enough corner case tests (for complex multi diamond shaped graphs), but I let zack judge this.

not sure I like too much the

cont, cont2 = [
          attr.evolve(c, ctime=now()) for c in sample_data_model["content"][:2]
      ]

a bit sad that the real reason there are different results in debian, but well, does not worth the time either, so ok

\o/

In D3548#87265, @ardumont wrote:

<mode=nitpciky>should be a comment, not a docstring </mode>

lol, that's cool, better agree to avoid modifying stuff on/off all the time heh.

I made it a docstring so it serves the purpose to also explain the allow_empty
parameter with such value (just above the docstring ;)

So with that in mind, is that ok as-is now?

<mode=nitpciky>should be a comment, not a docstring </mode>

I'm not very fond of yet another requirement file.

We do not use isort for now, so I'm a bit puzzled by the "The default isort configuration did not match the actual sorting of the
imports. " statement above.

In D3435#87224, @ardumont wrote:

In D3435#87210, @douardda wrote:

following @ardumont comment, the first 2 revisions are actually unrelated with this diff, so please submit them independently.
(however they can both be submitted as a single diff, but I'm not sure I'll buy the requirement-dev one, but let's discuss this on the proper diff)

@douardda he did already opened them, that's respectively D3519 D3520 ;)

one question (not checked nor reread the diff, just wondering): does this version of the loader generates the same SWHID for mercurial revisions than the one currently running? I can't see a test that prove that is true, but I may have missed it.

following @ardumont comment, the first 2 revisions are actually unrelated with this diff, so please submit them independently.
(however they can both be submitted as a single diff, but I'm not sure I'll buy the requirement-dev one, but let's discuss this on the proper diff)

but otherwise it's ok

ok but the commit message should just say something like "kill build_swh_snapshot() function" + one or 2 sentences explaining it's unneeded bc it's a oneliner used only once.

lgtm

closed by 28b35a18c723ba3d11ccf3beaf2008638aefb362

ok, but should check whether some other packages that uses this pytest plugin can be impacted.

inline expected_snapshot_id

inline SNAPSHOT_ID

In D3516#86518, @ardumont wrote:

I'm not sure we still need the hex form now.

ok nonetheless ;)

In D3501#86488, @ardumont wrote:

Otherwise, i think it's fine ;)
And according to the plan, the next step is to land it.

same with actual commit included

bump dep on swh.loader.core

Bump dep on swh.loader.core

bump dep on swh-loader-core

In D3501#86262, @ardumont wrote:

I'm very fine with landing a reasonably consistent and stable baseline any time you want.

In that case, i think a plan matching those properties could be:

• review/land first D3503 (so the check-snapshot implementation is complete, it checks up to the contents). It's not per say a blocker but that'd be more consistent.
• Then release new loader-core.
• Trigger back the builds of your mutiple diffs on the dvcs loaders (and land them when green, they should be ;)
• Then getting back here, rebase on latest loader-core and land this one.
• And then we (either you or me) should pick up those tests and replace the snapshots as dict with snapshot model objects (both core and again dvcs). <- that was my initial plan
• Optionally (or not), then we can come back here again and drop the from_dict conversion from the input... (only model object!!! at least in tests)

Does that sound reasonable?

looks ok, but I find it temptating to factorize(!) the missing objects looking pattern (not asked right now!).

rebase

no noqa

In D3501#86144, @ardumont wrote:

fwiw, i was heading towards making the transition you started *after* having deployed

the current implementation of "check-snapshot" (without that diff so with the internal
manipulation) And then commit the current diff ;)

Do you still want to land it first?

rebase

Forgot one occurrence

Reading the code dealing with snapshot branches in several storage implementations, it really seems to me that storing them as a dict-like structure has no advantage.

But I'd like to use the opportunity of this cleanup to go a bit further than "the minimal amount of work for pedantic correctness", and actually make changes that have a conceptual meaning.

make sure there is no doubt on who the dumb fellow is