unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: elaexuotee@wilsonb.com
To: zimoun <zimon.toutoune@gmail.com>
Cc: "Ludovic Courtès" <ludo@gnu.org>,
	"Pierre Neidhardt" <mail@ambrevar.xyz>,
	guix-devel@gnu.org
Subject: Re: how to "guix pack" a profile?
Date: Fri, 19 Jun 2020 11:52:10 +0900	[thread overview]
Message-ID: <35IQNXNGMD4MQ.2U3WRPXMLCVVA@wilsonb.com> (raw)
In-Reply-To: <861rmcvssb.fsf@gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 3864 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

  reply	other threads:[~2020-06-19  2:52 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-11  1:40 Using --manfistest with <profile>/manifest files elaexuotee
2020-06-13 20:36 ` Ludovic Courtès
2020-06-14 10:17   ` Pierre Neidhardt
2020-06-14 15:24     ` Ludovic Courtès
2020-06-15  7:52       ` Pierre Neidhardt
2020-06-16  9:44         ` Ludovic Courtès
2020-06-15  8:08       ` zimoun
2020-06-16  9:46         ` Ludovic Courtès
2020-06-16 11:33           ` elaexuotee
2020-06-16 13:42             ` zimoun
2020-06-17  0:45               ` elaexuotee
2020-06-17  7:58                 ` how to "guix pack" a profile? zimoun
2020-06-18  9:20                   ` elaexuotee
2020-06-18 23:49                     ` zimoun
2020-06-19  2:52                       ` elaexuotee [this message]
2020-06-19  8:30                         ` zimoun
2020-06-19 12:34                           ` elaexuotee
2020-06-19 15:38                             ` zimoun
2020-06-19 10:00                         ` zimoun
2020-06-19 12:16                           ` elaexuotee
2020-06-19 20:40                         ` Ludovic Courtès
2020-06-19 20:35                   ` Ludovic Courtès
2020-06-16  2:51   ` Using --manfistest with <profile>/manifest files George Clemmer
2020-06-16  4:27     ` elaexuotee
2020-06-17 19:09       ` George Clemmer
2020-06-16  9:38     ` zimoun
2020-06-16 14:03       ` George Clemmer
2020-06-16 15:09         ` zimoun
2020-06-16  9:50     ` Ludovic Courtès
2020-06-15  7:54 ` zimoun
2020-06-15 10:08   ` elaexuotee
2020-06-16  9:09     ` zimoun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=35IQNXNGMD4MQ.2U3WRPXMLCVVA@wilsonb.com \
    --to=elaexuotee@wilsonb.com \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    --cc=mail@ambrevar.xyz \
    --cc=zimon.toutoune@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).