Re: [Orchestration][RFC] A simple draft for channels

[Pjotr Prins]

Thanks Ricardo:

On Tue, Mar 20, 2018 at 11:41:33AM +0100, Ricardo Wurmus wrote:
> 
> Pjotr Prins <address@hidden> writes:
> 
> > On Mon, Mar 19, 2018 at 01:04:00PM +0100, Pjotr Prins wrote:
> >> Maybe we should start thinking that a channel is simply an
> >> architecture dependent Guix 'pack' of substitutes that includes the
> >> pre-built Guix git repo. When deployed in a container we can inject
> >> the keys. When this works we can design a pack repository, making the
> >> channels searchable.
> >
> > Continuing my line of thought: a binary channel in my mind is now a
> > compiled Guix package tree with Guix and possible adaptations (say a
> > special package for Ruby). In other words, a special (timed) version
> > of Guix sitting in /gnu/store/*named-guix-channel/bin/guix.
> 
> What you describe is essentially “guix pull”.  “guix pull” can already
> use a different branch or a different repository.
>
> It has at least two problems in this context:
> 
> 1) it only keeps a link to the “latest” Guix.  There is no way to
>    declare the use of a different variant of Guix.

No git hash, no tag, but could be added later.

> 2) it builds everything from source (Ludo’s branch for splitting the
>    target of “guix pull” into several derivations addresses this)

That is not good enough. But it seems to me that substitution is only
an implementation question.

> Maybe we should address the first problem next and allow for not only
> the latest Guix version to be retained.  This is not quite the same as a
> regular profile, because these different variants of Guix surely would
> provide colliding files.
> 
> The guix command would need to be changed to pick “latest” by default,
> but use a different variant if specified.
> 
> The workflow would be something like that:
> 
>     # fetch Guix from somewhere and record as “foobar”
>     guix pull --url=https://somewhere foobar
> 
>     # use that variant of Guix
>     guix --variant=foobar build hello

If we can substitute, that would work. And guix pull would have to be
binary too. But yes, with binary instant gratification, that would
really be a good start. Different versions can live on different URLs.

(hmm, what did I just write?)

> I don’t think this should be the only mechanism through which people can
> provide channels.  I wouldn’t want to have to essentially fork Guix.
> For a user this is a problem, too, because channels would no longer be
> composable (today I can compose multiple package collections with
> GUIX_PACKAGE_PATH).

I am not sure composability is required for most use cases. I think we
should keep it simple. I am happy to have channels act independently
if we can get it this year.

Pj.