Re: how to "guix pack" a profile?

[elaexuotee]

zimoun,

Thank you for you time.

Apparently, I am indeed missing some important conceptual details. I will come
back later when I know more.

Cheers and happy Guixing,

zimoun <zimon.toutoune@gmail.com> wrote:
> 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

signature.asc
Description: PGP signature