Re: potluck status

[Andy Wingo]

Greets,

Just a quick yes-and note:

On Tue 02 May 2017 04:26, Katherine Cox-Buday <address@hidden> writes:

> Andy Wingo <address@hidden> 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