On 03/19/2018 at 19:31 Pjotr Prins writes: > On Mon, Mar 19, 2018 at 02:21:35PM -0400, myg...@gmail.com 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.
Other people bash them, but I have used git modules a lot for hierarchical bio analysis and never hit a real issue. Maybe you could say more about the specific problem you see in this application? >> > 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) OK, but I prefer 'sudo git clean -dfx' because it innoculates me against any errors in 'make clean' logic. I should use ./pre-inst-env more ;-) > 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. I agree it is annoying, but maybe this is the cost of complete artistic source code freedom? And MIPS are so cheap these days, no? > And there are problems, usually with package updates that go out of > sync between my trees. guix as a submodule would avoid this, no? >> 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. If it were me, I would do source deployment w/ 'git clone --recurse-submodules', source update w/ 'git pull; git submodule update' and try to use bespoke project code to check out development and testing branches with git-subtree. You can capture the .go files by checking them into disposable "deploy" branches which you cam either pull to the target machine or a push to a non-naked repo. Am I missing something? - George
