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
