guix-devel
[Top][All Lists]
Advanced

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

Re: [Orchestration][RFC] A simple draft for channels


From: myglc2
Subject: Re: [Orchestration][RFC] A simple draft for channels
Date: Mon, 19 Mar 2018 14:21:35 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Hi Pjotr,

On 03/19/2018 at 13:04 Pjotr Prins writes:

> Let's start up again on this conversation in the context of
> deployment. I have a simple use case. For GeneNetwork we maintain
> GUIX_PACKAGE_PATH packages. It contains packages that ought to go in
> main line (such as python-gunicorn), but also packages that will never
> make it (such as a javascript twitter feed).
>
> Now we deploy multiple setups, which I'll simplify to development,
> testing and production here (there are more!). Each of these has a
> combination of a Guix git checkout and a GUIX_PACKAGE_PATH checkout.
>
> These git repo's are supposedly in sync with each other.
>
> Moving from one to the other, however, is too complicated and error
> prone. I can do it, but no one else really wants to. Even with my
> explanations it proves to be a royal pain.

How about making guix a submodule of the GeneNetwork repo?

> Now I need a way to no longer rebuild all .go files for Guix tree
> updates/changes. Not only between switching branches, but also when
> just running 'git pull' from Guix savannah. I find I have to do that
> very often. So often that I don't even try running make anymore
> without make clean. Anyone here share that experience?

Yes the guix make does seem rather fragile ;-) So I usually do ...

guix environment guix  -M 4 -c 4 --ad-hoc help2man git strace
rm -fr /home/g1/.cache/guile/ccache/*
sudo git clean -dfx
git pull
./bootstrap
./configure --localstatedir=/var --sysconfdir=/etc
make -j 10
make -j 10 check

This takes a while but it avoids me chasing spurious errors caused by
clashes between the state of my build directory and the upstream
changes ;-)

> One thing I could do is split out 3 git repos for every use case and
> update these individually not triggering rebuilds. And when I deploy
> on other machines move the complete repo across with .go files.

Have you considered a git-worktree for each of the development, testing
and production branches?

HTH - George



reply via email to

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