[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
https://guix-potluck.org/git/target.git" 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
cowpath.
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 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 :)
Cheers,
Andy
Re: potluck status, Katherine Cox-Buday, 2017/04/28
- Re: potluck status,
Andy Wingo <=