[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

how to "guix pack" a profile?

From: zimoun
Subject: how to "guix pack" a profile?
Date: Wed, 17 Jun 2020 09:58:40 +0200


On Wed, 17 Jun 2020 at 09:45, wrote:

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


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

Well, if I re-read correctly the emails and proposal, they are 2 points:

 1. Easily share a profile via "guix pack"
 2. A mean via recreating "manifest.scm" files

About the #2. it means changing a bit the format <profile>/manifest,
transition plan etc. and *if* someone comes with a prototype, it could
be happen, otherwise.  In the meantime, we need to work, so what could
happen is "--export-to-manifest" because it is doable and actionable.

The #1. is AFAIK new and it appears to me a good idea: add a feature to
"guix pack" and directly deal with profiles, i.e., use internally
<profile>/manifest, which appears to me doable and actionable.

Ludo, WDYT about "guix pack -p profile" to generate a (relocatable)
tarball or Docker image?  I mean if it is not already possible. :-)

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

>From my understanding, the way to go is the declarative via manifest.scm
and channel.scm.  Not profile.

For example, manifest.scm and channel.scm are easy to put under version
control system, they work trough all the Guix commands, etc..

You wrote elsewhere in this thread ``Naively, a profile is just a sum of
outputs'' which is correct, IMHO, but the correct level to interact with
and maintain this list is manifest.scm and channel.scm, again IMHO.

All the best,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]