[bug#54393] [PATCH 0/2] Add 'guix manifest' to "translate" commands to manifests

[Liliana Marie Prikler]

Am Dienstag, dem 15.03.2022 um 10:27 +0100 schrieb Ludovic Courtès:
> Hi,
> 
> Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> skribis:
> 
> > The current implementation is missing the most important feature,
> > which would be ‘guix manifest --profile $GUIX_PROFILE’ :)
> 
> True, we could add ‘-p’ and make it equivalent to ‘guix package
> --export-manifest’.
> 
> I think lack of ‘-p’ is not a showstopper though since ‘guix package
> --export-manifest’ remains available.
True, but implementing it as part of ‘guix manifest’ would open up a
way to easily declare a manifest for “merged” profiles.  These could be
applied in integration testing, e.g. you could merge multiple profiles
together and watch for intended and unintended side effects, for
instance regarding search paths.

> > Furthermore, one issue I have with both the existing and proposed
> > approaches is that both mandate the specification style,
> 
> The reasons for the specification style are:
> 
>   1. That it’s easier to implement reliably, since you just need to 
> rely on package specs.
> 
>   2. The resulting code is future-proof: if packages are moved from
>      one module to another, or if their variables are renamed, it 
>      still works.
> 
>   3. It’s a one-to-one mapping compared to the command line, which
>      hopefully makes it clearer.
> 
> However, ‘manifest->code’ existed before this patch series, so I
> think it’s beyond the scope of this review.
It's true that it's out of scope, but I don't want this to be
forgotten.  I can see the rationale of specification style for user
profiles, but for version-controlled package development manifests,
there are different incentives in play.  For example, you might want to
make sure that a package uses gcc-toolchain from (gnu packages
commencement) and not (google monorepo cc).

Cheers