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

[Pjotr Prins]

On Mon, Mar 19, 2018 at 02:21:35PM -0400, address@hidden wrote:
> > 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?

I don't like git submodules, unfortunately. I have plenty experience
there, and often not good. It works as long as you don't update the
modules ;)

I am OK with two git trees, there is no tight coupling between
GeneNetwork and Guix. But there is tight coupling between
GUIX_PACKAGE_PATH (guix-bioinformatics tree) and guix. I could
consider making guix-bioinformatics a module of guix. But I am sure I
am in for pain there too.

> > 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

Mine is comparable, but even more rigorous:

  screen -S guix-build # I tend to build in screen
  env -i /bin/bash --login --noprofile --norc
  ./pre-inst-env guix environment guix --ad-hoc help2man git strace \
    pkg-config less vim binutils coreutils grep guile guile-git guile-json \
    gcc nss-certs --no-grafts
  bash # you may want this shell
  rm -rf autom4te.cache/ # to be sure
  make clean
  ./bootstrap
  ./configure --localstatedir=/var
  make clean    # to be really sure
  make clean-go # to be even surer
  make -j 

(forget the make check)

but, yes, the point is that I have to do this too often and it takes a
long time. So much that I thrust my hand through the monitor every
time I have to start again. It is costing me monitors.

And there are problems, usually with package updates that go out of
sync between my trees.

> 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 ;-)

I think we agree.

> > 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?

Hmmm. That may be helpful. I should try that. 

Still does not solve my deployment problems.

Pj.
--