From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pjotr Prins Subject: Re: [Orchestration][RFC] A simple draft for channels Date: Tue, 20 Mar 2018 14:10:37 +0100 Message-ID: <20180320131037.GA22625@thebird.nl> References: <87bmhq6ytg.fsf@mdc-berlin.de> <87shar5wp8.fsf@gmail.com> <20180319120400.GA13807@thebird.nl> <20180320070224.GA20987@thebird.nl> <87r2ofc9lu.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53095) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eyH6V-0002L1-Kr for guix-devel@gnu.org; Tue, 20 Mar 2018 09:15:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eyH6S-0008PE-E9 for guix-devel@gnu.org; Tue, 20 Mar 2018 09:15:03 -0400 Received: from mail.thebird.nl ([95.154.246.10]:57968) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eyH6S-0008MY-7n for guix-devel@gnu.org; Tue, 20 Mar 2018 09:15:00 -0400 Content-Disposition: inline In-Reply-To: <87r2ofc9lu.fsf@elephly.net> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ricardo Wurmus Cc: guix-devel@gnu.org, Ricardo Wurmus Thanks Ricardo: On Tue, Mar 20, 2018 at 11:41:33AM +0100, Ricardo Wurmus wrote: >=20 > Pjotr Prins writes: >=20 > > 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 th= e > >> 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. >=20 > What you describe is essentially =E2=80=9Cguix pull=E2=80=9D. =E2=80=9C= guix pull=E2=80=9D can already > use a different branch or a different repository. > > It has at least two problems in this context: >=20 > 1) it only keeps a link to the =E2=80=9Clatest=E2=80=9D 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=E2=80=99s branch for splittin= g the > target of =E2=80=9Cguix pull=E2=80=9D into several derivations addre= sses 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. >=20 > The guix command would need to be changed to pick =E2=80=9Clatest=E2=80= =9D by default, > but use a different variant if specified. >=20 > The workflow would be something like that: >=20 > # fetch Guix from somewhere and record as =E2=80=9Cfoobar=E2=80=9D > guix pull --url=3Dhttps://somewhere foobar >=20 > # use that variant of Guix > guix --variant=3Dfoobar 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=E2=80=99t think this should be the only mechanism through which p= eople can > provide channels. I wouldn=E2=80=99t 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.