rebase

ok but please explain why in your commit message...

as reported by vlorentz, duplicate of D3811

as said in the commit message, It must be updated jointly in 30-swh-schema.sql
(including after a rebase...)

Just to make is clear, my main objective here is to have a seatbelt for the mirror scenario: prevent a mirror with updated code but not-yet-updated database from even running until the DB migration script has been executed.

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