Re: Tracking and inspecting how Guix changes over time

["Ludovic Courtès" <ludo@gnu.org>]

Hello!

Christopher Baines <mail@cbaines.net> skribis:

> In summary, I've started playing around with a new service, I'm
> currently calling it the "Guix Data Service". The code is here [1], it's
> based off of Ricardo's excellent Mumi, and at the moment only does one
> thing, a basic comparison of two different versions (commits) of Guix
> for the few commits it has data for. I've got it up and running here
> [2].
>
> 1: https://git.cbaines.net/guix/data-service/
> 2: https://prototype-guix-data-service.cbaines.net/

Woow, impressive!  I’m sure this is going to be useful in different
ways: for patch review, which is your main target, but also for things
like the hpcguix-web interface, which could provide information about
package history, or to bisect packaging issues, possibly connected to a
‘guix weather’ service.

> The following links relate to a couple of patches affecting the Ruby
> build system.
>
> Issue:            https://issues.guix.info/issue/34385
> Patchwork series: https://patchwork.cbaines.net/project/guix-patches/list/?series=535
> Laminar job:      https://laminar.cbaines.net/jobs/patchwork-test-series/889
> Git commits:      https://git.cbaines.net/guix/patches/log/?h=series-535-version-1&qt=range&q=base-for-series-535-version-1..series-535-version-1
> Comparison:       https://prototype-guix-data-service.cbaines.net/compare?base_commit=6fd72f7094885dc3dbb10431996c445251094915&target_commit=7d70e05d7064f31a8de60b04d22ac16c1953b7a9

Neat!  With tight integration of all these things, coupled with info
from ‘guix weather’ and ‘guix lint’ and ‘guix challenge’, for example,
we’d have an unequaled QA tool!

> As far as I can see, guix pull/the channels code directly evaluates some
> Guile code from the source repository. It would be great if this could
> somehow be isolated to guard against any malicious patches that try to
> attack the machine running the Guix Data Service, I haven't thought much
> about how yet.
>
> Similarly, using the inferiors approach to extract out information from
> Guix requires running a REPL from the target Guix. This could also pose
> security issues. I was wondering if it was possible to run the REPL
> within a container, to at least isolate it a bit from the system.

Yes, we should definitely run that code in a container.  Note that, for
‘guix pull’, I think it’s OK to run that code on the user’s machine
as-is in the sense that the user is going to run code coming from the
channels they specified anyway.

For an automated system like this, it’s a bit different, so using a
container makes a lot of sense.  I’d suggest having an option directly
in (guix inferior) to allow users to choose whether to run an inferior
in separate name spaces.  WDYT?

(There’s also (ice-9 sandbox) but I think it’s too restrictive to be
applicable here.)

> One other point is that while I've gone with the "web service" approach
> here, I think it would be very useful to have a "guix compare" command
> that did something similar.

Indeed.  Part of it is already available in ‘guix pull’, but we could
certainly move the common logic in (guix inferior compare), say.  Let’s
try to have as much of this available as UI-independent Guix modules.

This is really exciting, thanks for sharing!

Ludo’.