From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: Re: 02/09: guix: store: Make register-items transactional, register drv outputs Date: Mon, 01 Apr 2019 21:43:02 +0200 Message-ID: <87pnq5jyux.fsf@gnu.org> References: <20190204192241.15758.66035@vcs0.savannah.gnu.org> <20190204192243.D1BD820B84@vcs0.savannah.gnu.org> <87wom8pqbi.fsf@gnu.org> <87o97gcc3w.fsf@cune.org> <877edcjgbj.fsf@gnu.org> <87sgv11ujj.fsf@cune.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:54912) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hB2pk-0004dm-4e for guix-devel@gnu.org; Mon, 01 Apr 2019 15:43:05 -0400 In-Reply-To: <87sgv11ujj.fsf@cune.org> (Caleb Ristvedt's message of "Mon, 01 Apr 2019 12:53:36 -0500") 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: Caleb Ristvedt Cc: guix-devel@gnu.org Hello, Caleb Ristvedt skribis: >> A problem is that we should not pull in these two modules here, because >> they are conceptually at a higher level (they have to do with talking to >> a separate daemon process.) >> >> So perhaps a first step would be to re-arrange things, probably along >> these lines: >> >> =E2=80=A2 Move the .drv parsing code and the record type = from >> (guix derivations) to, say, (guix store derivations). >> >> =E2=80=A2 Re-export all these bindings from (guix derivations). >> >> =E2=80=A2 Move =E2=80=98store-path?=E2=80=99, =E2=80=98derivation-path= ?=E2=80=99 & co. (everything below line >> 1745 in guix/store.scm) to, say, (guix store files). Re-export >> appropriately so the API remains unchanged. >> >> At this point, (guix store =E2=80=A6) modules won=E2=80=99t have to use = (guix store) and >> (guix derivations) at all. >> >> How does that sound? > > As we found out on IRC yesterday, https://bugs.gnu.org/15602 is causing > this to fail. If I understand correctly, the workaround involves trying > to make sure that modules that use (guix memoization) are compiled > before (guix memoization) is (and it turns out that once that's solved > the same issue occurs with (guix config)). Considering that the > module-import-compiled builders just do a depth-first-search for scheme > source files ordered alphabetically, that's a bit tricky. I ended up > making a dummy module, (gnu build dummy), that does nothing but use > (guix config) and (guix memoization), and the tests now pass. > > Does a better workaround exist? Could we pass an ordered list of files > to the builder somehow instead of just a directory? But then again, > changing every module-import-compiled would mean rebuilding the > world. Eh. We could go with the clunky workaround for now. Then we should fix =E2=80=98compiled-modules=E2=80=99 in a way that does no= t force a full rebuild. That can be done by having a keyword argument to select between the correct implementation and the buggy one; in (guix packages), we=E2=80=99d ask for the buggy one so that we don=E2=80=99t trig= ger a rebuild. As for how to fix it, we could use (guix build compile) which already does the right thing. > Oh, also, should I just copy all the copyright lines from the old > modules to the new ones? Ideally you=E2=80=99d just copy the relevant lines; if it=E2=80=99s too tri= cky to find out which lines correspond to what, you could copy them all (I=E2=80=99d ar= gue it=E2=80=99s not an unreasonable thing to do.) Thanks! Ludo=E2=80=99.