From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Wingo Subject: Re: potluck status Date: Tue, 02 May 2017 08:58:21 +0200 Message-ID: References: <87inloir9c.fsf@gmail.com> <87mvawngdj.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56714) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d5RmC-0003PI-Hy for guix-devel@gnu.org; Tue, 02 May 2017 02:59:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d5Rm9-0003ai-HE for guix-devel@gnu.org; Tue, 02 May 2017 02:59:12 -0400 Received: from pb-sasl2.pobox.com ([64.147.108.67]:56666 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d5Rm9-0003KZ-Ai for guix-devel@gnu.org; Tue, 02 May 2017 02:59:09 -0400 In-Reply-To: <87mvawngdj.fsf@gmail.com> (Katherine Cox-Buday's message of "Mon, 01 May 2017 21:26:32 -0500") 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: Katherine Cox-Buday Cc: guix-devel@gnu.org Greets, Just a quick yes-and note: On Tue 02 May 2017 04:26, Katherine Cox-Buday writes: > Andy Wingo writes: >> & as for dev/testing/prod/etc -- I have no idea :) I'm not really an >> ops person, so I can only speculate, and anyone can do that as well as I >> can :) I think with guix-potluck.org my main focus is to let people >> share work-in-progress Guix packages immediately. I can imagine many >> ways this could relate to a sort of devopsy workflow but I can't pretend >> to be an expert here :) > > Sorry, I didn't mean to be too dev-opsy. All I really meant is just like > we have a staging branch/channel now that eventually gets rolled into > master, we could have a dev branch/channel which is really unstable and > experimental, a staging branch/channel (which is test in my vernacular), > and master branch/channel (which is prod in my vernacular). > > Potluck seemed appropriate for dev for the same reasons it seemed > appropriate for scala/sbt. Oh I didn't mean to disparage this kind of workflow, rather the opposite! Apologies if I didn't communicate that right -- I think there's lots of cool stuff to do in this area, and I look forward to seeing what people come up with. As far as having dev and stable channels of Guix itself -- you're right, having a channel facility could be a step towards Guix itself having a stable branch and a development branch and perhaps something in-between too. Really interesting to explore this space mentally. In the past, Guix developers have always said "sure but probably now isn't the right time" when the topic of production vs development branches was brought up -- and that could be the answer now too, but when channels are implemented that certainly does seem like a good mechanism for it. One thing about Guix packages is that currently every package should have a unique "bindings" -- I mean, that you can't usefully have a package bound to variable V in module M, and have different versions of module M in A/M.scm and B/M.scm. The potluck facility gives somewhat unique names M to the modules, "solving" this problem there. You can of course have as many (package (name "foo")) values as you like, and Guix will know about all of them and their versions. But to be loadable they need to have different bindings. This makes channels inappropriate for directly implementing Guix dev/testing/prod workflows, I think -- you want to have the same module M, but three versions of it to choose from. So implementing a dev/testing/prod thing in Guix would require solving this problem. It's not so much a Guix problem as a Guile problem, in a way, or a mismatch between how Guix wants to think of available packages and how Guile wants to think about bindings. Something to solve! Andy