unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: elaexuotee@wilsonb.com
Cc: guix-devel@gnu.org
Subject: how to "guix pack" a profile?
Date: Wed, 17 Jun 2020 09:58:40 +0200	[thread overview]
Message-ID: <861rmexgwf.fsf@gmail.com> (raw)
In-Reply-To: <268B906X3RZH5.3NHG3ABUCOVPN@wilsonb.com>

Hi,

On Wed, 17 Jun 2020 at 09:45, elaexuotee@wilsonb.com 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,
simon


  reply	other threads:[~2020-06-17  7:58 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                 ` zimoun [this message]
2020-06-18  9:20                   ` how to "guix pack" a profile? elaexuotee
2020-06-18 23:49                     ` zimoun
2020-06-19  2:52                       ` elaexuotee
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=861rmexgwf.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=elaexuotee@wilsonb.com \
    --cc=guix-devel@gnu.org \
    /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).