From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thompson, David" Subject: Re: The future of 'guix environment' Date: Wed, 30 Aug 2017 21:28:13 -0400 Message-ID: References: <87ziahytsq.fsf@member.fsf.org> <20170830155634.GB2248@jurong> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58614) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dnEHJ-0002zU-Qe for guix-devel@gnu.org; Wed, 30 Aug 2017 21:28:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dnEHI-0003fs-IG for guix-devel@gnu.org; Wed, 30 Aug 2017 21:28:17 -0400 Received: from mail-ua0-x22d.google.com ([2607:f8b0:400c:c08::22d]:38119) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dnEHI-0003fQ-C5 for guix-devel@gnu.org; Wed, 30 Aug 2017 21:28:16 -0400 Received: by mail-ua0-x22d.google.com with SMTP id j46so23696365uag.5 for ; Wed, 30 Aug 2017 18:28:15 -0700 (PDT) In-Reply-To: <20170830155634.GB2248@jurong> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Andreas Enge Cc: guix-devel Thanks for the feedback, everyone. I'm going to try to address what everyone has been discussing. =E5=AE=8B=E6=96=87=E6=AD=A6, I agree with Andreas that making a new command= is undesirable and would just lead to confusion. I think a single tool can support the major use cases well. I'd go so far as to say that I will have failed if two commands are necessary. We can always add subcommands to 'guix environment' itself, if that turns out to be better for usability. We will see. As for a 'guix environment up' command, I think that's worth thinking about but I'm going to avoid thinking about it too much because we're still quite a ways off from being able to make this happen. My general feeling is the same as Ricardo's, though, that 'guix environment' should just spawn the services automatically and there would have to be some notion of "attaching" to an existing session. This topic deserves a whole separate thread when the time comes. Ricardo, you are correct that we would lose the ability to use the guix.scm file for both 'guix environment' and 'guix build'. In practice I don't actually use my guix.scm file this way, so I think it's worth breaking, but maybe you (or someone else) actually uses this and we should think more about it? I wasn't very clear about whether ephemeral or cached would be the new default. I don't think there is one default for all cases, I think it's more context sensitive. When the user specifies --load, I think caching should be the default because loading such a file means that you are working on a project for which you'd like a persistent environment. When the user specifies ad-hoc packages, caching would be disabled because most likely they are running a one-off job. For example, 'guix environment ruby -- irb' should spawn a Ruby REPL, discarding the environment when the user exits. 'guix environment --load=3Dguix.scm' would check for a cached profile, use it if it is there, otherwise build the profile and cache it for next time. 'guix environment', without --load or any packages specified, would be equivalent to 'guix environment --load=3Dguix.scm'. A little "convention over configuration" will greatly improve usability, I think. There's really only 2 major use cases, and I want those to work without having to fiddle with a bunch of command line flags. All the underlying flags will still be there to fiddle with for those who are interested. - Dave