Re: how to "guix pack" a profile?

[zimoun <zimon.toutoune@gmail.com>]

Dear,

On Fri, 19 Jun 2020 at 11:52, elaexuotee@wilsonb.com wrote:

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

Others?  For example me.  With Pierre, we spent some time at Guix Days
to propose a new format.

> 1. Composable profiles,

This is already possible.

> 2. Sharing "light" profiles buy sending only the "recipe.scm" instead
> of an entire container.

I am not sure to get what is a "light" profile but from my understanding
what you want here already exist and it is manifest.scm+channel.scm.

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

See below.

>> 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:

I have the impression that the discussion is going nowhere.

Make what you called "recipe.scm" or modify "<profile/manifest" to
become an acceptable "--manifest" is doable.  Note that the idea is not
new either.  As I said, all the technical material is here.  But Ludo
and others (me) are not convinced that it will pay off because the
general case is hard.  Well, to be concrete, there are 2 possible next
actions:

 a) prototype the new format and implement it
 b) make an approximation exposed with "--export"

Frankly, I doubt that a) happens because no one will do the tough work.
Therefore, b) is pragmatic.


>>>> (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 couldstore package transformations as manifest entry properties.
>>
>> However, that’ll be an approximation: the exact implementation of
>> ‘--with-input’, for instance, can vary over time.

This snippet of quotation shows that it is not "easy" for the general
case.  And the transformation using "--load-path" has not been evoked.
For example:

--8<---------------cut here---------------start------------->8---
(define-module (foo)
 #:use-module (guix packages)
 #:use-module (guix profiles) ;; imagine it is used
 #:use-module (gnu packages base))

(define (crazy-transformation pkg)
  "Could do really complicated things"
  (package
    (inherit pkg)
    (name (string-append "ex-" (package-name pkg)))))

(define bonjour
  (package
    (inherit hello)
    (name "bonjour")))

(define-public crazy-bonjour
  (crazy-transformation bonjour))
--8<---------------cut here---------------end--------------->8---

then "guix install -L /path/to/foo ex-bonjour".


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

You are missing the difficulty to make it concretely, I guess. :-)


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

Thank you for the ideas.  Especially the two ones:

 1. create an environment from a profile
 2. pack a profile

Well, I do not know if they will happen but it should be cool to have.


I am going to move on since we already raised all the points, I guess. :-)


All the best,
simon