Re: how to "guix pack" a profile?

[elaexuotee]

Ludo, Pierre, would you mind commenting? Starting to doubt my sanity here.

> Well, from my understanding, any profile point to /gnu/store/<hash>-profile.

Exactly. This is something we both know. I feel like we are not communicating
well with each other.

You emphasize that declarative package management with "manifest.scm" is the
way to go. I agree but wanted to point out that

    $ guix package -m manifest.scm

produces a different /gnu/store/<hash>-profile, depending on when it's run (or
more precisely, depending on which channel commits guix resolves for the
invocation).

You know that, of course, but the point I try to make is that "manifest.scm"
and "channels.scm" are *not enough* to uniquely determine a specific
/gnu/store/<hash>-profile. We need to separate out the concepts of "declarative
profile management" and "deterministic profile regeneration."

What Pierre (and others?) initially proposed---what I am re-proposing---is that
we put a blob of Guile into the profiles that is capable of uniquely and
completely generating the profile where it resides.

> For which use case?

The examples I gave in my previous email...
I am not sure what's getting miscommunicated here.

> Well, let say there is a profile which could be a mess and I only see
> two usages currently uncovered:
> 
>  1. create an environment based on this profile; either to temporarily
>    extend it (which is AFAIK already more or less covered), either to
>    isolate it,
>  2. pack it for sharing with your colleague.

Sure, about the only new feature now would be to guix pack an existing profile.

However, it's not too hard to think of potential uses or features users may
want in the future:

1. Composable profiles,
2. Sharing "light" profiles buy sending only the "recipe.scm" instead of an
   entire container.
3. guix archive --manifest
4. guix profile --manifest-from-recipe <profile>/recipe.scm

The last one there is intended to be the tool for "migrate from imperative to
declarative" user profile management, starting from a given profile.

> What you describe here is exactly what Pierre and other have proposed.
> And the work-to-do is to prototype the format of what you called
> "recipe.scm", which means equivalently in the previous emails change the
> format of <profile>/manifest.

I agree. However, in previous emails I have tried to make a rebuttal to Ludo's
argument than the best we can do is *approximate* a manifest.scm.

See https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00098.html:

>>> (Ludo)
>>> As far as faithfulness is concerned, we should also keep in mind that we
>>> don’t always have all the information needed to reconstruct what’s in a
>>> profile.  For example, we lack information about the package
>>> transformation options that were used (if any),
>>
>> (Pierre)
>> Like `--with-input'?
>> I didn't think of this.  Can't we extend the format then to include all
>> transformation options, with future-proof provisions?
>
> (Ludo)
> We could store package transformations as manifest entry properties.
>
> However, that’ll be an approximation: the exact implementation of
> ‘--with-input’, for instance, can vary over time.

However, with `time-machine' and a given `guix environment' or `guix profile'
invocation, we are able to deterministically resolve a
/gnu/store/<hash>-profile, no? Better yet, this is in a future-proof way, no?
If that is so, then why not canonify this profile recipe in guile code instead
of what is needed now: guile + bash? What am I missing here?


Just to be clear, I would be more than thrilled with a --from-profile option to
`guix pack'. However, I am trying to make a case that "first class profiles"
is both feasible and may pay back more in maintenance cost than it consumes.

signature.asc
Description: PGP signature