From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thompson, David" Subject: Re: The future of 'guix environment' Date: Thu, 31 Aug 2017 20:29:35 -0400 Message-ID: References: <87inh3n4x4.fsf@gnu.org> 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]:54938) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dnZq6-0001wN-Tv for guix-devel@gnu.org; Thu, 31 Aug 2017 20:29:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dnZq5-0002bD-Hq for guix-devel@gnu.org; Thu, 31 Aug 2017 20:29:38 -0400 Received: from mail-ua0-x234.google.com ([2607:f8b0:400c:c08::234]:36656) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dnZq5-0002an-Av for guix-devel@gnu.org; Thu, 31 Aug 2017 20:29:37 -0400 Received: by mail-ua0-x234.google.com with SMTP id g16so1943862uah.3 for ; Thu, 31 Aug 2017 17:29:37 -0700 (PDT) In-Reply-To: <87inh3n4x4.fsf@gnu.org> 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: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Cc: guix-devel On Thu, Aug 31, 2017 at 11:16 AM, Ludovic Court=C3=A8s wrote= : > Heya, > > "Thompson, David" skribis: > >> If you've followed along this far, great! Now here's my list of >> proposed changes: >> >> 1) Add a caching mechanism. The environment profile should get built >> once, and then a symlink to it should be created in $PWD and >> registered as a GC root. This will, of course, require re-using some >> 'guix package' code to delete the profile. For the sake of the rest >> of this post, let's say that a --cache flag does this, and a --update >> flag forces a rebuilding of the cached profile. > > One way to put it is that =E2=80=98guix environment=E2=80=99 would be syn= tactic sugar > for =E2=80=98guix package -p $PWD/.guix-environment=E2=80=99, right? Yeah, I guess so. I've never used the -p flag and don't know if it should stay. I'll try to preserve it and see how that goes! > This would make =E2=80=9Cguix environment=E2=80=9D stateful: if you have = something in > cache, that=E2=80=99s what you get (it could be old versions of =E2=80=9C= foo=E2=80=9D and > =E2=80=9Cbar=E2=80=9D), but if you don=E2=80=99t, you get the current ver= sions of =E2=80=9Cfoo=E2=80=9D and > =E2=80=9Cbar=E2=80=9D. Is this what you have in mind? Yes. For regularly hacked on project environments I think this is the most useful behavior. Because then, much like my regular user profile, I can update at a time when I feel ready to do so, rather the current situation where I'm forced to rebuild and deal with potential breakage or long download/compile times. > I prefer the current stateless behavior, whereby =E2=80=9Cguix environmen= t > --ad-hoc foo bar=E2=80=9D always gives you the same environment, given a = Guix > commit. But maybe we can make =E2=80=9Cguix environment=E2=80=9D (no arg= uments) > stateful, and keep =E2=80=9Cguix environment foo bar baz=E2=80=9D statele= ss? That's what I had in mind. In my head there's two important cases: the on-the-fly, stateless environment, and the persistent environment that you update every now and then when you feel like living on the edge. 'guix environment foo bar' (ad-hoc being the new default) should absolutely be stateless, just like it is now. >> 3) Change how --load behaves. Instead of evaluating a file and >> expected a package object in return, instead expect a >> record. This would provide a declarative way to >> specify the complete environment: which packages to pull in, whether >> to purify the environment (--pure), whether to run in a container >> (--container), whether to give the container network access >> (--network), etc. Command line flags would take precedence over what >> is specified in the config file. --load may only appear *once* in the >> command line args, whereas now it many appear N times. > > +1, probably with automatic conversion of to , as > I wrote in another message. Ah, this is a clever hack! I will do that. Thanks for suggesting it. >> 4) Make 'guix environment' with no other args operate like 'guix >> environment --cache --load=3Dguix.scm'. 'guix.scm' is a placeholder >> name for whatever we decide the conventional name for an environment >> config should be. Throwaway environments (such as 'guix environment >> ruby -- irb') would not have caching turned on by default, because >> that would quickly become a burden. > > +1, except perhaps for --cache, not sure. I think I will convince you it's a good idea. ;) > Also, I would prefer the convention to be =E2=80=9C.guix.scm=E2=80=9D (to= avoid > confusion with the (guix) module, and to mimic existing conventions > followed by Travis and all that.) Sure, that's fine with me, but FYI there are existing conventions of using non-hidden files. Bundler uses 'Gemfile', Docker uses 'Dockerfile', Vagrant uses 'Vagrantfile', npm uses 'package.json', etc. > Bonus: honor =E2=80=9C.guix.json=E2=80=9D (see ) as one way > to get us closer to world domination. Maybe someone else can add that after I do everything else. :) > I=E2=80=99d rather not add a new command, which means we=E2=80=99ll have = to agree to > break the =E2=80=9Cguix environment=E2=80=9D CLI. I think that=E2=80=99s= OK, but we should > discuss it. I agree. We can discuss more when I have patches. I will probably have additional questions as I go. The biggest unknown for me so far is how environment profile generation management will work (if it should even exist), but I'll get the basics sorted out first. Thanks for your feedback! - Dave