all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: YOANN P <yoann_mac_donald@hotmail.com>
To: "George Clemmer" <myglc2@gmail.com>, "Ludovic Courtès" <ludo@gnu.org>
Cc: "guix-devel@gnu.org" <guix-devel@gnu.org>
Subject: RE: ~/.guix-profile/manifest usage with "guix package -m [manifest]" / "guix pack -m [manifest]" etc..
Date: Mon, 1 Oct 2018 22:40:09 +0000	[thread overview]
Message-ID: <VI1P18901MB002949F96CD645EE758706F7DBEF0@VI1P18901MB0029.EURP189.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <cucmurxzaj5.fsf@gmail.com>

>De : George Clemmer <myglc2@gmail.com>
>
>>Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hello,
>>
>> YOANN P <yoann_mac_donald@hotmail.com> skribis:
>>
>>> I was thinking than "~/.guix-profile/manifest" was a valid manifest file due to his name, but it seems not that is the case from the error i've got
>>>
>>> https://pastebin.com/Z7h2t5mL
>>>
>>> After some search , i've finally understand that the instantiated profile couldn't be used as source profile for "guix package -m" etc... due to the same words despite use case and is a bit confusing
>>
>> I agree it’s a bit confusing.  The manual does make it clear that -m
>> expects source code that evaluates to a manifest object, though.
>>
>>> https://gnunet.org/bot/log/guix/2016-05-27#T1040380
>>>
>>> It will be really convenient to only have the instantiate profile to easily maintain it in a vcs system.
>>>
>>> Despite what ludo said in 2016 on IRC, i didn't see those options yet.
>>> Did i missed them ?
>>> If not implemented yet, any news about this feature ? :)
>>
>> No news I’m afraid :-) but I’ve opened an issue so we keep track of it:
>>
>>   https://issues.guix.info/issue/32844

Hi George,

>Hi Ludo’,
>
>Your bug doesn't capture some other manifest issues ...
>
>"~/.guix-profile/manifest" and 'guix package --manifest=FILE' use the
>same term/filename for markedly different things and the doc is silent
>on the distinction. While "~/.guix-profile/manifest" may be internal to
>Guix, users will inevitably trip across it and be confused (as YOANN did
>here, and I did a year ago).
>
>We might avoid confusion and make documentation easier by renaming one
>of these. Consider ...
>
>We are using "~/.guix-profile/manifest" in a way that is consistent with
>a common use, e.g., shipping manifest, which specifies information not
>in the associated order and at a level of detail that can only be
>determined at shipment (e.g. serial number).
>
>Our use of manifest in 'guix package --manifest=FILE' is rather less
>intuitive. In fact this FILE is more like an order than a manifest,
>IMO. As the doc says, [the manifest] 'FILE must return a “manifest”
>object, which is roughly a list of packages'. If we were to rename this
>a "package-list" or "package-spec", this would be more intuitive and
>self-explanatory (at least to me, an English speaker), and make the doc
>easier to write/understand.
>
>YOANN hit an error when trying to do 'guix package -m
>~/.guix-profile/manifest'. Why would one want to do this? Maybe to
>(re)produce a configuration previously reached by a series of 'guix
>package -i' operations?
>

Exactly that use case.
As said, i'm looking a way to have "a snapshot" of my profile to versioning it and be able to reproduce the exact same environnement associated if needed.
This way we could easily share the exact same environnement in dev, desktop case etc...

I don't know the utility of the instantiate manifest and the relations with it, but more precisly, this is how i had imaginated the instantiate manifest file at first and now how i would like to see / use it :

- Keep the informations who can only be determined at shipment
- All the informations necessary to build the environneent are there too and would override on the fly the .scm system definitions for the pakages list inside the profile. This way if the Guix system scm files was updated, guix would be always able to build the profile.

I don't know the implications of this feature, but Guix definilty need it if it didn't already exist :)

>In most situations, rather than a "~/.guix-profile/manifest" file, one
>wants to use a 'guix package --manifest=FILE', since this is more
>durable over time and easier to maintain (e.g. in SCC).
>

and please, even be able to read it from /dev/stdin.
it seems not available at now and is one of the last things i'm missing to be able to install a manifest through SSH.
My use case is to be able to install a profile on a rootless computer through SSH if needed.
I am today able to install some packages on a computer without root access and without guix installed in this way :

ssh guixpack@XXX.XXX.XXX.XXX -- '-R -S /opt/bin=/bin -S /etc=etc hello' | tar -xzf -

cloud_init.sh (debian stretch) : https://gist.github.com/rockandska/52d1a76b87e1e7bd6ce137c4ddab4b11

and what i would like to achieve is to be able to pipe a manifest from the rootless computer to the remote Guix server like this :

/tmp $ cat local_manifest | ssh guixpack@XXX.XXX.XXX.XXX -- '-R -m /dev/stdin -S /opt/bin=/bin -S /etc=etc hello' | tar -xzf -

Not sure about the security as is,not sure if it is the best way to do it too, but i had fun to test it and i would like to test it as an "anonymous" service for fun too ^^

>So, IMO, it would be useful to have something like ...
>
>guix package --manifest-from-profile -p ~/.guix-profile > FILE
>
>... which returns a "minimally specified" FILE that allows 'guix package
>--manifest=FILE' to reproduce "~/.guix-profile".
>
>- George

Yoann

  reply	other threads:[~2018-10-01 22:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-25 19:55 ~/.guix-profile/manifest usage with "guix package -m [manifest]" / "guix pack -m [manifest]" etc YOANN P
2018-09-26 10:19 ` Ludovic Courtès
2018-09-27 20:03   ` YOANN P
2018-09-27 21:49     ` Alex Kost
2018-09-29 16:33     ` Ludovic Courtès
2018-10-01 20:17   ` George Clemmer
2018-10-01 22:40     ` YOANN P [this message]
2018-10-02 12:46     ` Ludovic Courtès
2018-10-02 16:55       ` George Clemmer
2018-10-02 20:41         ` Ricardo Wurmus
2018-10-02 21:35           ` George Clemmer
2018-10-08 12:26           ` Ludovic Courtès
2018-10-10 14:07             ` George Clemmer
2018-10-11 13:44               ` Ludovic Courtès

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

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

  git send-email \
    --in-reply-to=VI1P18901MB002949F96CD645EE758706F7DBEF0@VI1P18901MB0029.EURP189.PROD.OUTLOOK.COM \
    --to=yoann_mac_donald@hotmail.com \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    --cc=myglc2@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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.