From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: Building guix-modular with cuirass Date: Sat, 12 May 2018 19:17:23 -0700 Message-ID: <877eo8fgek.fsf@gmail.com> References: <87a7tpc8vw.fsf@gmail.com> <87po2gyhem.fsf@gnu.org> <87r2mwk0o7.fsf@gmail.com> <878t93nlha.fsf@gnu.org> <20180508212356.obhxtfvhc6ysjkjr@abyayala> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49759) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fHgZq-0001Up-ER for help-guix@gnu.org; Sat, 12 May 2018 22:17:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fHgZn-0004iQ-91 for help-guix@gnu.org; Sat, 12 May 2018 22:17:34 -0400 In-Reply-To: <20180508212356.obhxtfvhc6ysjkjr@abyayala> (Nils Gillmann's message of "Tue, 8 May 2018 21:23:56 +0000") 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: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: help-guix --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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/latest. >> At that point we won=E2=80=99t have this kind of problem anymore. >>=20 >> Ludo=E2=80=99. >>=20 > > 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=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", 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. =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlr3oDMACgkQ3UCaFdgi Rp1VCg//fuVuce6VjX4uevCFf1+eK8Yb76hwXdwzK/abjuavYYSXm8TGgOVqQjen /sPGWcbBylkaKHnzwtWE7/1GCwE7q9F5cQcn8viihB56uVS1F1V1i/XXagWMOHwf 9y2sHhgeMijaDPzzf0pm0S7kE9bWM2PYMfHF16YnY4kFpyP0CTiQNGVR5uAO7Dz8 UT2xedWuOOHDimiADIuOa15X4SI+1c6MTbYqekr9DMm1zfdXDcOzwWQJzek8gYgZ ilunYpFy4jeTuCLckpgelWMO+PtYAkYt6J8aiBE6Y1HF2gfb6sUxGZ/MzXjsZW8n VexuCmzGxK4f40Jv35r8BKE0WcCsFxLBOSZkMB32EnvdUghUqcDjYQkQ01mmaxWq s/JcIEFvLHE/thrZ04Zgrq2cP1B2d3n9GOUqtANLjlx0+ZRHDgC++nq4W9+vx8DG ru5dAZAUJj4L1FRNNKB4ayrUogjRR74p216ARMxgddsNyHa3mpu77wPY7B248PgA vMDvBkoydAvKgoHPYZmGYamLbB0dLevkcJb9jaRx+1mJlDEfjpspc7tfhSUgZb/n t1b2JIclR+UNQh4ztLFdN50uIsDHaRRD7P9WKsF4oR7C6C3+NtUGAGFtVAlDToJv P5kiK63gGIw30wC9GO/IaTCD98mAQuN1LaB57SjzFTcXlERnRv4= =/NGP -----END PGP SIGNATURE----- --=-=-=--