[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: potluck status

From: Andy Wingo
Subject: Re: potluck status
Date: Fri, 28 Apr 2017 16:06:52 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Hi :)

On Fri 28 Apr 2017 15:41, Katherine Cox-Buday <address@hidden> writes:

> Andy Wingo <address@hidden> writes:
>> With that I think I'd like to move to a "use" phase where I just sit
>> back and see how people use the thing :)  WDYT?
> I am very excited about this functionality for all of the reasons you
> enumerated. I don't have any time at the moment, but I was (and still
> am) interested in getting Scala and sbt packaged, and I think this is
> how I would begin. I could also see packaging a few private work-related
> things as potluck packages for use by myself and others.
> A couple of questions:
> 1. When Guix grows channel support, will it have a concept of
>    dev->test->prod?
> 2. Would it make sense for the dev channel to be expressed in terms of
>    potluck packages?
> I'm not very active in the community at the moment, but I wanted to
> chime in and say +1, and thanks for the effort.

Great to hear the interest.  There are many many many unknowns at this
point.  The basic "channel" facility could be just like "git remote" --
you do "guix channel add testing https://..../testing.git";.  "git
channel pull" or so could update that checkout.  "git channel enable"
makes a channel active for you by default.  I guess you would probably
also want to to specify also a set of active channels for a given guix
command; e.g. "guix package --channels=testing --install my-package".

Concretely you could "git channel add potluck"; to get the potluck channels.
Currently what you have to do is manually check out that repo and do
"guix package -L /path/to/checkout --install my-package".  So an initial
"guix channel" would just pave that guix-packages-in-a-git-repository

As for Scala and sbt and everything -- I think potluck packages are most
appropriate for "leaf" packages.  For packages that form
"infrastructure" like sbt and all, I think you will probably want to
integrate more closely in Guix.  But I don't know.

& 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 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 :)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]