Re: 02/09: guix: store: Make register-items transactional, register drv outputs

[Ludovic Courtès]

Hello,

Caleb Ristvedt <address@hidden> 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:
>>
>>   • Move the .drv parsing code and the <derivation> record type from
>>     (guix derivations) to, say, (guix store derivations).
>>
>>   • Re-export all these bindings from (guix derivations).
>>
>>   • Move ‘store-path?’, ‘derivation-path?’ & 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 …) modules won’t 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 ‘compiled-modules’ in a way that does not 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’d ask for the buggy one so that we don’t trigger 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’d just copy the relevant lines; if it’s too tricky to find
out which lines correspond to what, you could copy them all (I’d argue
it’s not an unreasonable thing to do.)

Thanks!

Ludo’.