Thanks Ricardo: On Tue, Mar 20, 2018 at 11:41:33AM +0100, Ricardo Wurmus wrote: > > Pjotr Prins <pjotr.publi...@thebird.nl> 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.