Re: Channel dependencies

[ludo@gnu.org (Ludovic Courtès)]

Hello!

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis:

> the attached patch allows channel authors to declare other channels as
> dependencies of their own channel.  In addition to explicitly requested
> channels, “guix pull” will now also download and build channels that
> have been declared as dependencies in the file ‘.guix-channel’ in the
> repository root.
>
> An example of a simple .guix-channel file is this:
>
> (channel
>  (version 0)
>  (dependencies
>   (channel
>    (name guix-bimsb)
>    (url "https://github.com/BIMSBbioinfo/guix-bimsb"))))
>
> What do you think?

I think that’s great.  :-)

> From 1783c17582906df970c7e68e89d761619a35caeb Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus <rekado@elephly.net>
> Date: Sat, 13 Oct 2018 08:39:23 +0200
> Subject: [PATCH] guix: Add support for channel dependencies.
>
> * guix/channels.scm (%channel-meta-file): New variable.
> (channel-meta, channel-instance-dependencies): New procedures.
> (latest-channel-instances): Include channel dependencies.
> (channel-instance-derivations): Build derivation for additional channels and
> add it as dependency to the channel instance derivation.
> * doc/guix.texi (Channels): Add subsection "Declaring Channel Dependencies".

[...]

> +(define (channel-meta instance)
> +  "Return an S-expression read from the channel INSTANCE's description file,
> +or return #F if the channel instance does not include the file."
> +  (let* ((source (channel-instance-checkout instance))
> +         (meta-file (string-append source "/" %channel-meta-file)))
> +    (and (file-exists? meta-file)
> +         (call-with-input-file meta-file read))))

As a general pattern, I’d suggest declaring <channel-metadata> record
type along with a ‘read-channel-metadata’ procedure that takes care of
“parsing” and metadata version handling.  That way parsing code is in
just one place and the rest of the code can happily deal with
well-formed records.

> +(define (channel-instance-dependencies instance)
> +  "Return the list of channels that are declared as dependencies for the given
> +channel INSTANCE."
> +  (or (and=> (assoc-ref (channel-meta instance) 'dependencies)
> +             (lambda (dependencies)
> +               (map (lambda (item)
> +                      (let ((get (lambda* (key #:optional default)
> +                                   (or (and=> (assoc-ref item key) car) default))))
> +                        (let ((name (get 'name))
> +                              (url (get 'url))
> +                              (branch (get 'branch "master"))
> +                              (commit (get 'commit)))
> +                          (and name url branch
> +                               (channel
> +                                (name name)
> +                                (branch branch)
> +                                (url url)
> +                                (commit commit))))))
> +                    dependencies)))
> +      '()))

I’d recommend ‘match’ for the outer sexp, and then something like the
‘alist-let*’ macro from (gnu services herd) in places where you’d like
to leave field ordering unspecified.

Then I think it would make sense to add the ‘dependencies’ field to
<channel-instance> directly (and keep <channel-metadata> internal.)
Each element of the ‘dependencies’ field would be another
<channel-instance>.

Actually ‘dependencies’ could be a promise that reads channel meta-data
and looks up the channel instances for the given dependencies.
Something like that.

Thoughts?

Chris raises interesting issues.  I think it’s OK to first come up with
an implementation that has some limitations but works with the simple
use cases we have in mind.

Thanks for working on it!

Ludo’.