I'm not sure I'm a huge fan of some of the hacks required (removing the cur/self/... arguments), but on the purely technical side this looks very good.

The only thing I would question is whether it would be worth it to start directly by factorizing that in the RPC itself, in order to force ourselves finding generic solutions that would work for the rest of the remote APIs?

I'm not sure I'm a huge fan of some of the hacks required (removing the cur/self/... arguments),

How else can we avoid this though?

Cons:

Some Python magic
Won't play well with static analysis tools.

People might as well.
I do not see another way to factorize some more though.

Also, tests are fine! So that's a good sign it does what i think it does.

I don't think it's clear to me what happens during import and the implications here (since we run code here to declare methods/functions/class, instead of simply declaring those).
That might be my biggest concern.

In that regard, that might be a clue to push further below that kind of code...

The only thing I would question is whether it would be worth it to start directly by factorizing that in the RPC itself, in order to force ourselves finding generic solutions that would work for the rest of the remote APIs?

... (as seirl hinted at)...

Cheers,

In D505#9661, @seirl wrote:

The only thing I would question is whether it would be worth it to start directly by factorizing that in the RPC itself, in order to force ourselves finding generic solutions that would work for the rest of the remote APIs?

Indeed. I just moved all the code to swh.core.api and it looks even nicer this way (no need to put the for loop at the root of a module). I'll write a Diff later today.

In this current state, i have errors on make test, the base of which seems to be this:

TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases

steps to reproduce:

cd swh-core
arc patch D507
cd ../swh-indexer
arc patch D505
make test

You need to merge D513 as well

In D505#10074, @ardumont wrote:

In this current state, i have errors on make test, the base of which seems to be this:

TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases

Details are at P312

TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases

Details are at P312

Well, it was a side-step on my part, i needed to arc patch the D513 on the objstorage as well.
Tests are fine after that.