Re: Using --manfistest with <profile>/manifest files

[elaexuotee@wilsonb.com]

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

Thank you for the direct reply, zimoun.

> [The problem] is a pragmatic one. As any good Zen says: "Now is better than
> never. Although never is often better than *right* now."

Okay. If that is the case, then I very much empathize with the problem.

> Going from imperative/sequential "install, pull, remove" way to the
> declarative manifest.scm way, in the general case, needs to change the
> format of <profile>/manifest (or add another file). Which means
> transition plan, etc.. Otherwise, on the technical level, all the
> material is there.

That said. This makes me wonder that we may be thinking of different things
altogether.

The discussion seems to have congealed around smoothing the transition to
declarative profile management for users. However, the proposal I have in mind
is *first class profiles*. I am thinking of a file that can be fed to the
--manifest (or some potential future equivalent) option of various guix
commands. This hypothetical file would let users operate directly on profiles
as needed.

My current specific use case for this is packing the *development environments*
produced by `guix environment'.

> I do not see why it is straightforward for some cases.

    guix environment --ad-hoc <package>

can be indirectly packed via

    guix pack <package>

unless I am missing something. Otherwise, users are at an impasse.

> Because your use case -- pack an existing profile for sharing -- is not
> really related to transform <profile>/manifest to a valid manifest.scm,
> if I understand correctly.  And I agree with you that it should be
> possible to pack an existing profile (created by any mean).
> 
> Does "pack --profile-name" fit your needs?

I am not quite sure this works. From the manual:

> ‘--localstatedir’
> ‘--profile-name=NAME’
>      Include the “local state directory”, ‘/var/guix’, in the resulting
>      pack, and notably the ‘/var/guix/profiles/per-user/root/NAME’
>      profile—by default NAME is ‘guix-profile’, which corresponds to
>      ‘~root/.guix-profile’.
> 
>      ‘/var/guix’ contains the store database (*note The Store::) as well
>      as garbage-collector roots (*note Invoking guix gc::).  Providing
>      it in the pack means that the store is “complete” and manageable by
>      Guix; not providing it pack means that the store is “dead”: items
>      cannot be added to it or removed from it after extraction of the
>      pack.

I do not see how to use this with the transitory /gnu/store/<hash>-profile
produced by a `guix environment' invocation. Also, my intention is simply to
provide the profile's environment, not include the local state directory.

Put more simply, I want to be able to produce a tarball/container capable of
reproducing `guix environment --container <package>'. I think this would be
very useful.

Am I just failing to grok something fundamental? Thoughts?


More generally, I think first class profiles could be both a powerful feature
and an important future-proofing against extra maintenance burden. Profiles are
a central concept to guix usage. They form the atomic unit with which users
interact. Wanting to tarball a profile is just one use case, but future guix
commands (guix merge, anyone?) or future --manifest options (guix archive,
anyone?) seem likely to directly benefit from an existing infrastructure that
supports store profiles being created, recreated and munged.




zimoun <zimon.toutoune@gmail.com> wrote:
> Dear,
> 
> On Tue, 16 Jun 2020 at 20:33, elaexuotee@wilsonb.com wrote:
> >> 1. We can only approximate that actual profile content; storing
> >>    an approximate ‘manifest.scm’ along with the profile would IMO be
> >>    deceptive.
> >
> > Is this a technical barrier or a pragmatic one?
> 
> [...]
> 
> > If the problem is of pragmatics, then at the very least I would be interested
> > in hearing a delineation of the challenges. I think this could be helpful for
> > the discussion though.
> 
> It is a pragmatic one. As any good Zen says: "Now is better than never.
> Although never is often better than *right* now."
> 
> Going from imperative/sequential "install, pull, remove" way to the
> declarative manifest.scm way, in the general case, needs to change the
> format of <profile>/manifest (or add another file). Which means
> transition plan, etc.. Otherwise, on the technical level, all the
> material is there.
> 
> So it is some work and it is not clear that it will pay off.
> 
> 
> >> Yeah, I think our goal is just to provide a tool to migrate from the
> >> “imperative” way to the declarative way.  Once people have gotten
> >> started with manifests, they no longer need that migration tool.
> >
> > Would you mind commenting on the use case that I started this thread with?
> > Specifically, I was trying to `guix pack' a `guix environment'. The equivalent
> > is straightforward for purely --ad-hoc environments but not otherwise.
> 
> I do not see why it is straightforward for some cases.
> 
> 
> > Personally, I have already encountered several instances where this would have
> > been useful. I also think it would be just plain cool to have the ability to
> > pack up, containerize, and share arbitrary profiles with non-guix users.
> 
> Well, I have re-read your initial message and maybe miscommunication
> here. :-)
> 
> Because your use case -- pack an existing profile for sharing -- is not
> really related to transform <profile>/manifest to a valid manifest.scm,
> if I understand correctly.  And I agree with you that it should be
> possible to pack an existing profile (created by any mean).
> 
> Does "pack --profile-name" fit your needs?
> 
> If not, yes packing an existing profile could be a feature to "guix
> pack" -- doing transparently something similar to the Leo's suggestion
> -- because it is an internal consumption of these <profile>/manifest
> files.
> 
> 
> All the best,
> simon



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