Re: Guix Data Services: whishlist about SWH

[zimoun <zimon.toutoune@gmail.com>]

Hi,

On Mon, 24 Feb 2020 at 18:10, Ludovic Courtès <ludo@gnu.org> wrote:

> >> Using the Software Heritage (SWH) API [3], does it seems a good idea
> >> to add SWH coverage somewhere in the Guix Data Services?
>
> That’s a great idea!  Maybe it’s not a good idea to store that info in
> the database of the Data Service though.  (Web browsers could query the
> SWH API by themselves actually, though it’d be nice to have a JS-free
> variant.)

It is out of my skills. :-)

What I have in mind is:
 1. Green/red button like SWH stamp! :-) Green for archived in SWH and
red for not yet, and maybe orange for scheduled.
 2. A chart for the coverage.

Well, the point 1. works at the package level and should be done
entirely inside the webbrowser (modulo JS-free).
However, point 2. cannot be checked on the fly, IMHO and so needs to
be stored somewhere in the Data Service.

I have no idea where to look to for example start something about the
point 1. Clue accepted. ;-)


> > I think the first step towards this would be to experiment with fetching
> > data from the Software Heritage API. Do you know how you'd fetch data
> > about the output from a fixed output derivation (like harfbuzz)?
>
> The ‘archival’ linter does that.  See also the examples at:
>
>   https://guix.gnu.org/blog/2019/connecting-reproducible-deployment-to-a-long-term-source-code-archive/

Thank you for the pointer. I will try to find my way in the linter code. :-)


Thinking about connections between Guix/Nix and SWH and discussing
with lewo, it could be also nice to "push" for each evaluation of
Cuirass all our upstream sources to the SWH listener. Well, the SWH
listener is still a work-in-progress but currently it accepts
something in the format of 'sources.json'. A patch implementing that
is pending [1] and in the near future (after soonish the patch's
review) this 'sources.json' will be produced by the Website... Hum?
The question is then: what will produce this 'sources.json' file?
Cuirass or Data Services?

If I understand Clément's concern about Cuirass, he is not in favour
to add too much Guix only features to Cuirass. So Cuirass does not
seem the right place.
Well, the Data Service could do that. For each evaluation, it produces
this 'sources.json' file and it serves it a a place that the SWH
listener could ingest and so schedule some fetching.
There is still questions to minimize the resource consumption (more on
SWH side than on our side), but that another story.

In this case, Guix will be more robust, especially about time travelling.

What do you think?

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39547#29
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39547#35


All the best,
simon