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.touto...@gmail.com> wrote: > Dear, > > On Fri, 19 Jun 2020 at 11:52, elaexuo...@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
