From: Chris Marusich <cmmarusich@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: help-guix <help-guix@gnu.org>
Subject: Re: Building guix-modular with cuirass
Date: Sat, 12 May 2018 19:17:23 -0700 [thread overview]
Message-ID: <877eo8fgek.fsf@gmail.com> (raw)
In-Reply-To: <20180508212356.obhxtfvhc6ysjkjr@abyayala> (Nils Gillmann's message of "Tue, 8 May 2018 21:23:56 +0000")
[-- Attachment #1: Type: text/plain, Size: 2216 bytes --]
Nils Gillmann <ng0@n0.is> writes:
> Ludovic Courtès transcribed 800 bytes:
>>
>> In the near future, I want ‘guix pull’ to install a ‘guix’ binary as
>> opposed to simply dropping a bunch of modules in ~/.config/guix/latest.
>> At that point we won’t have this kind of problem anymore.
>>
>> Ludo’.
>>
>
> Not trying to derail this thread too much, but could you explain that a
> bit more Ludovic? I'm curious.
> This is moving beyond the current change with modular guix (which still
> drops a bunch of modules into the store and compiles them), correct?
I think he's referring to his latest comments here:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22629
Today, the "guix" command is a thin wrapper, as explained here:
https://lists.gnu.org/archive/html/help-guix/2017-09/msg00092.html
Going forward, I think Ludo is suggesting that we should no longer rely
on the thin wrapper to delegate business logic to whatever is installed
in ~/.config/guix/latest; instead, "guix pull" would basically build a
new Guix (including the "guix" command) in a profile located at
~/.config/guix/current. Each user would use their own "guix" command.
Currently, when a user invokes a command like "guix package -i foo", the
path of execution is roughly like this:
1. /run/current-system/profile/bin/guix (or, if it's a foreign
distribution and the user has installed Guix according to the manual,
this will be /usr/local/bin/guix, which points to
/var/guix/profiles/per-user/root/guix-profile/bin/guix)
2. ~/.config/guix/latest/${whatever_module_was_invoked}
But after the proposed improvement, the path of execution would be:
1. ~/.config/guix/current/bin/guix
2. ~/.config/guix/current/${whatever_module_was_invoked}
So, every Guix installation would truly be self-contained, unlike the
current situation, where the same thin "guix" command is shared by every
user. And since ~/.config/guix/current is basically just a profile, I
think we'd also get roll-back for free, which is nice because currently
roll-back after a "guix pull" isn't as easy as it could be
Ludo, please feel free to correct me if I'm misrepresenting anything.
--
Chris
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2018-05-13 2:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-27 9:10 Building guix-modular with cuirass Mathieu Othacehe
2018-04-30 13:04 ` Ludovic Courtès
2018-04-30 18:29 ` Mathieu Othacehe
2018-05-01 20:56 ` Ludovic Courtès
2018-05-02 13:52 ` Mathieu Othacehe
2018-05-09 22:05 ` Ludovic Courtès
2018-05-08 21:23 ` Nils Gillmann
2018-05-13 2:17 ` Chris Marusich [this message]
2018-05-13 7:48 ` swedebugia
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=877eo8fgek.fsf@gmail.com \
--to=cmmarusich@gmail.com \
--cc=help-guix@gnu.org \
--cc=ludo@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 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.