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

2022-02-14 Thread Ludovic Courtès
Hello,

Thanks for working on it!

Josselin Poiret  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’.





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

2022-02-14 Thread Josselin Poiret via Bug reports for GNU Guix
Hello everyone,

I've been working on this for a bit, trying to find the best approach.

First, let me try to summarize the different ways in which Guix can be
run, and how it is built:

* From a `guix pull` profile.  This is the most common.  The `guix
  pull` profile's manifest file holds specific metadata describing the
  channels that were used to build the generation, which can be
  fetched by `(current-channels)` from (guix describe).

* From a built Guix inside the store, outside a `guix pull` profile.
  This is what happens when the user hasn't `guix pull`ed yet after a
  Guix System installation, for example.  Here, the only available
  metadata is the one embedded in (guix config) by the build process,
  and (current-channels) returns that one.

* From a Git checkout.  Here, there is no build metadata at all.

Furthermore, there are two ways to build Guix: either through the
`guix` package definition, which uses the Makefile, or through
`build-aux/build-self.scm` which uses `guix/self.scm`.

Here, I use the second method, since it's how the current guix is most
likely built.  This means that, with proper care, all the derivations
already have their output in the store.

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?  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.

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.

Best,

Josselin Poiret (4):
  gnu: ci: Move generic channel building code.
  gnu: Rename channel-build-system and channel-source->package.
  gnu: current-guix: Support when running outside a checkout.
  gnu: package-management: Memoize current-guix.

 etc/system-tests.scm|  3 +-
 gnu/ci.scm  | 40 +--
 gnu/packages/package-management.scm | 60 +++--
 guix/channels.scm   | 51 
 4 files changed, 102 insertions(+), 52 deletions(-)

-- 
2.34.0