Fetching a channel set over HTTP

Fetching a channel set over HTTP

[Ludovic Courtès]

Hello Guix!

My colleague Emmanuel Agullo came up with an interesting use case and
suggestion that we got around to play with.  If you paste the following
snippet as ~/.config/guix/channels.scm:

--8<---------------cut here---------------start------------->8---
(use-modules (guix http-client)
             (json)
             (guix channels))

(define-syntax alist-let
  (syntax-rules ()
    ((_ alist (variable rest ...) body ...)
     (let ((variable (assoc-ref alist (symbol->string 'variable))))
       (alist-let alist (rest ...) body ...)))
    ((_ alist () body ...)
     (begin body ...))))

(define (alist->channel-introduction alist)
  (alist-let alist (signer commit)
             (make-channel-introduction commit
                                        (openpgp-fingerprint signer))))

(define (alist->channel alist)
  (alist-let alist (name url branch commit introduction)
             (channel (name (string->symbol name))
                      (url url)
                      (branch branch)
                      (commit commit)
                      (introduction
                       (and=> introduction alist->channel-introduction)))))

(pk 'channels
 (map alist->channel
      (vector->list
       (json->scm
        (http-fetch/cached
         "https://people.bordeaux.inria.fr/lcourtes/tmp/channels.json")))))
--8<---------------cut here---------------end--------------->8---

… then anytime you run ‘guix pull’, you’ll actually get the channels I
published in that ‘channels.json’ file (generated by
‘guix describe -f json’).

Since it’s JSON, you’re not executing arbitrary code; the authentication
and downgrade prevention mechanisms are in effect too, although the file
could direct you to unauthenticated third-party channels (authentication
is always required for the ‘guix’ channel itself) and there’s no
downgrade prevention if you’re using ‘time-machine’ rather than ‘pull’.

The use cases are:

  1. Within a team, everyone would default to downloading an agreed-upon
     channels file.  Someone in the team is responsible for keeping that
     file up-to-date etc.

  2. One could define a “stable distro” by publishing such a file:
     they’d pin channels to specific commits and change those commits
     only when the packages they care about have been tested.

  3. As someone distributing software, you could publish such a file and
     provide simple instructions to deploy the software.

  4. Cuirass, qa.guix, etc. could publish a channels file for each
     issue, branch, or jobset so that users can trivially reproduce it.

What if we exposed the snippet above (1) as a ‘download-channels’
procedure, say, and (2) at the CLI level?

  guix time-machine -C https://example.org/channels.json -- …

Thoughts?

Ludo’.

Re: Fetching a channel set over HTTP

[Emmanuel Agullo]

Hello Ludo, hello Guix,

Thank you once again for the snippet and thank you also for sharing 
with the guix community the idea of integrating it!

Nothing to add except that it would be awesome! (And maybe if it
was not explicit enough: another possible application is that it would 
be a convenient way to set up a tunable rolling-release only slightly
delayed to ensure one can follow the latest guix(/channels) 
commit(s) for which binaries (or a subset of them) are available.)

Best regards,

Manu

----- Mail original -----
> De: "Ludovic Courtes" <ludovic.courtes@inria.fr>
> À: guix-devel@gnu.org
> Cc: "Emmanuel Agullo" <emmanuel.agullo@inria.fr>
> Envoyé: Vendredi 19 Janvier 2024 10:36:30
> Objet: Fetching a channel set over HTTP

> Hello Guix!
> 
> My colleague Emmanuel Agullo came up with an interesting use case and
> suggestion that we got around to play with.  If you paste the following
> snippet as ~/.config/guix/channels.scm:
> 
> --8<---------------cut here---------------start------------->8---
> (use-modules (guix http-client)
>             (json)
>             (guix channels))
> 
> (define-syntax alist-let
>  (syntax-rules ()
>    ((_ alist (variable rest ...) body ...)
>     (let ((variable (assoc-ref alist (symbol->string 'variable))))
>       (alist-let alist (rest ...) body ...)))
>    ((_ alist () body ...)
>     (begin body ...))))
> 
> (define (alist->channel-introduction alist)
>  (alist-let alist (signer commit)
>             (make-channel-introduction commit
>                                        (openpgp-fingerprint signer))))
> 
> (define (alist->channel alist)
>  (alist-let alist (name url branch commit introduction)
>             (channel (name (string->symbol name))
>                      (url url)
>                      (branch branch)
>                      (commit commit)
>                      (introduction
>                       (and=> introduction alist->channel-introduction)))))
> 
> (pk 'channels
> (map alist->channel
>      (vector->list
>       (json->scm
>        (http-fetch/cached
>         "https://people.bordeaux.inria.fr/lcourtes/tmp/channels.json")))))
> --8<---------------cut here---------------end--------------->8---
> 
> … then anytime you run ‘guix pull’, you’ll actually get the channels I
> published in that ‘channels.json’ file (generated by
> ‘guix describe -f json’).
> 
> Since it’s JSON, you’re not executing arbitrary code; the authentication
> and downgrade prevention mechanisms are in effect too, although the file
> could direct you to unauthenticated third-party channels (authentication
> is always required for the ‘guix’ channel itself) and there’s no
> downgrade prevention if you’re using ‘time-machine’ rather than ‘pull’.
> 
> The use cases are:
> 
>  1. Within a team, everyone would default to downloading an agreed-upon
>     channels file.  Someone in the team is responsible for keeping that
>     file up-to-date etc.
> 
>  2. One could define a “stable distro” by publishing such a file:
>     they’d pin channels to specific commits and change those commits
>     only when the packages they care about have been tested.
> 
>  3. As someone distributing software, you could publish such a file and
>     provide simple instructions to deploy the software.
> 
>  4. Cuirass, qa.guix, etc. could publish a channels file for each
>     issue, branch, or jobset so that users can trivially reproduce it.
> 
> What if we exposed the snippet above (1) as a ‘download-channels’
> procedure, say, and (2) at the CLI level?
> 
>  guix time-machine -C https://example.org/channels.json -- …
> 
> Thoughts?
> 
> Ludo’.