In D3800#94004, @vlorentz wrote:

Yeah but I didn't find a very satisfying solution either. Well, I guess I could do something like this:

CONVERTERS: Dict[str, Callable[[BaseDb, Dict[str, Any]], BaseModel]] = {
    **{
        type_: lambda db, obj: converter(obj)
        for (type_, converter) in object_converter_fn.items()
    },
    "directory": directory_converter,                          
    "raw_extrinsic_metadata": raw_extrinsic_metadata_converter,
    "revision": revision_converter,                            
    "release": release_converter,                              
    "snapshot": snapshot_converter,                            
}

But it's not much of an improvement

LGTM, but see my comment for a possible improvement.

as discussed on IRC, I'm not feeling very comfortable with the format stuff (in RawExtrinsicMetadataCore) but meh.

thx

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?