From mboxrd@z Thu Jan 1 00:00:00 1970 From: swedebugia Subject: Re: Building guix-modular with cuirass Date: Sun, 13 May 2018 09:48:39 +0200 Message-ID: <52012edd-1524-1077-0280-48e4aae821a4@riseup.net> References: <87a7tpc8vw.fsf@gmail.com> <87po2gyhem.fsf@gnu.org> <87r2mwk0o7.fsf@gmail.com> <878t93nlha.fsf@gnu.org> <20180508212356.obhxtfvhc6ysjkjr@abyayala> <877eo8fgek.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50643) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fHlhf-0007xP-5O for help-guix@gnu.org; Sun, 13 May 2018 03:46:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fHlhb-0000IP-46 for help-guix@gnu.org; Sun, 13 May 2018 03:45:59 -0400 In-Reply-To: <877eo8fgek.fsf@gmail.com> Content-Language: sv-FI List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: =?UTF-8?Q?Ludovic_Court=c3=a8s?= , Chris Marusich Cc: help-guix@gnu.org On 2018-05-13 04:17, Chris Marusich wrote: > Nils Gillmann writes: > >> Ludovic Court=C3=A8s transcribed 800 bytes: >>> In the near future, I want =E2=80=98guix pull=E2=80=99 to install a =E2= =80=98guix=E2=80=99 binary as >>> opposed to simply dropping a bunch of modules in ~/.config/guix/lates= t. >>> At that point we won=E2=80=99t have this kind of problem anymore. >>> >>> Ludo=E2=80=99. >>> >> 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 stil= l >> 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=3D22629 > > 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", th= e > 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 ever= y > 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. Sounds like nice improvement to me. :) Guix pull seems still to be the least robust and least user friendly=20 part of Guix according to my experience.