bug#53210: [WIP PATCH 0/4] Make current-guix work when run outside a Git checkout

[Ludovic Courtès]

Hello,

Thanks for working on it!

Josselin Poiret <dev@jpoiret.xyz> skribis:

> This is only a WIP as there are some unresolved things: I've disabled
> authentication, since I'm currently testing my own unsigned patches.
> Should we indiscriminately enable it?  This would cause some issues
> for people that have their own 'guix channel.  Maybe we could enable
> authentication if the channel URL is the default one?

How about adding a keyword argument to ‘channel-build-system’,
defaulting to true?

> Also, when I tried to replace the guix in the installer by
> (current-guix), it ended up building the Guix derivation multiple
> times, even though the package is memoized and the package->derivation
> process should be cached.

‘current-guix’ returns a fresh package object every time it’s called:

 (define-public current-guix
   (lambda ()
     …
     (package …)))

This defeats the object-to-derivation cache, which relies on object
identity (eq?).  So yes, you definitely have to turn it into ‘mlambda’.

Why that’s no enough, I don’t know.

> There's a bit of rift between what the ci uses (renamed here to
> channel-profile-build-system) and what current-guix uses, since the
> former builds a profile as a package, whereas the latter simply builds
> the derivation for the 'guix channel.  This avoids creating profile
> collisions when the package is added to the system profile, but it
> also means we don't get the package cache generation.

As discussed on IRC, I think the file-level collisions are fine: unless
I’m mistaken, it’s the ‘manifest’ file of the real profile that “wins”,
so it doesn’t really matter that the ‘guix’ package also provides a
‘manifest’ file.

What’s more problematic though is that it means that
“/run/current-system/profile/bin/guix describe” would now fail (I think?
Can you confirm?) since it gets its provenance data from the profile
it’s in.

WDYT?

Ludo’.