rebase

remove remaining mentions of the "simplified metadata deposit"

typos and some fixes according to comments

In T2767#52345, @moranegg wrote:

I need to reflect on this.
There were two major reasons for which we use the slug:

1. create an origin

I've merged T2757 in this since there indeed identical

adapt according to vlorentz' comment

typo (thx vlorentz)

Rebase, updates and fix according to moranegg's comments

I also think that if we use the "blueprint" terminology, then the blueprint section should list all the specifications, implemented or not, but make it very clear what's done, in-progress or only planned.

• I wonder if it would not make more sense to put spec-meta-deposit.rst and spec-sparse-deposit.rst within blueprint.rst since these are other "use cases"
• I don't really get the point of the specs/spec-technical.rst file - it should be deleted (maybe keep one or 2 paragraphs in there)
• I think dev-info.rst and sys-info.rst should be moved in a subsection ("Reference" or "Technical Doc" or something)
• I think the tests/tests_HAL.rst file should not be in the docs

fix formatting in the docstring of client_command_parse_input()

Agree with @vlorentz, we should not clean a given SWHID, it's either valid or not

rebase

rebase

fix a few more oopsies reported by vlorentz and ardumont

Fixes according to vlorentz' comments

rebase

rebas

rebase

rebase

rebase

rebase + review comments

split code blocks in 2 as requested by vlorentz

It remains unclear to me how this diff addresses the original timeout problem. I see the beneficial effect of having a lazy loading mechanism and cache to reduce the load, but not to prevent the timeouts to occur in the first place (thus failing to fill the cache).

I also think this external_identifier should go away, the spec is rich (aka complicated) enough without we adding some layers :-)

also note that making the slug a MUST (server-side) is not valid w.r.t. the specs ("The client MAY supply a Slug header")

same as the previous one, ok once green

I'm fine with this, can be landed as soon as tests are ok.

Any reason for not landing this? (@marmoute ? do you keep your request for changes?)

see comments

So the test fails on jenkins because they use the hg command from the system (since mercurial is oddly enough, not a dependency of swh-loader-mercurial) and on stretch, mercurial is 4.8
Using mercurial 5.5 is ok.

In D4354#108710, @moranegg wrote:

Is this chapter saved anywhere? or is it so deprecated it shouldn't be saved?

rebase

Define and use the SWH acronym

fixes and improvements suggested by maoranegg (big thx)

typos (thx ardumont)

I would expect the commit message to be a bot more explanatory: either this new test case adds some tested aspects that were not tested before, and it should mention it, or it does not, and it should also mention it explaining this new test is the base for futures extended ones in a more manageable way (what's the "updatable" stands for, if I get this right).

should be ok now (even if via ImmutableDict :-) )