From mboxrd@z Thu Jan 1 00:00:00 1970 From: myglc2@gmail.com Subject: Re: [Orchestration][RFC] A simple draft for channels Date: Mon, 19 Mar 2018 16:18:29 -0400 Message-ID: <878tanom3u.fsf@gmail.com> References: <87bmhq6ytg.fsf@mdc-berlin.de> <87shar5wp8.fsf@gmail.com> <20180319120400.GA13807@thebird.nl> <87d100ncy8.fsf@gmail.com> <20180319183127.GA16931@thebird.nl> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44676) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ey1Er-0006fu-SL for guix-devel@gnu.org; Mon, 19 Mar 2018 16:18:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ey1Em-0001ck-Qk for guix-devel@gnu.org; Mon, 19 Mar 2018 16:18:37 -0400 Received: from mail-qk0-x22c.google.com ([2607:f8b0:400d:c09::22c]:44164) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ey1Em-0001cI-LX for guix-devel@gnu.org; Mon, 19 Mar 2018 16:18:32 -0400 Received: by mail-qk0-x22c.google.com with SMTP id h14so14268041qkj.11 for ; Mon, 19 Mar 2018 13:18:32 -0700 (PDT) In-Reply-To: <20180319183127.GA16931@thebird.nl> (Pjotr Prins's message of "Mon, 19 Mar 2018 19:31:27 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Pjotr Prins Cc: guix-devel@gnu.org, Ricardo Wurmus On 03/19/2018 at 19:31 Pjotr Prins writes: > On Mon, Mar 19, 2018 at 02:21:35PM -0400, myglc2@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