From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: The future of 'guix environment' Date: Thu, 31 Aug 2017 17:16:39 +0200 Message-ID: <87inh3n4x4.fsf@gnu.org> References: 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]:60500) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dnRD3-0003hj-J4 for guix-devel@gnu.org; Thu, 31 Aug 2017 11:16:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dnRCz-0005If-Ic for guix-devel@gnu.org; Thu, 31 Aug 2017 11:16:45 -0400 In-Reply-To: (David Thompson's message of "Wed, 30 Aug 2017 09:22:13 -0400") 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: "Thompson, David" Cc: guix-devel 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 synta= ctic sugar for =E2=80=98guix package -p $PWD/.guix-environment=E2=80=99, right? This would make =E2=80=9Cguix environment=E2=80=9D stateful: if you have so= mething in cache, that=E2=80=99s what you get (it could be old versions of =E2=80=9Cfo= o=E2=80=9D and =E2=80=9Cbar=E2=80=9D), but if you don=E2=80=99t, you get the current versi= ons of =E2=80=9Cfoo=E2=80=9D and =E2=80=9Cbar=E2=80=9D. Is this what you have in mind? I prefer the current stateless behavior, whereby =E2=80=9Cguix environment --ad-hoc foo bar=E2=80=9D always gives you the same environment, given a Gu= ix commit. But maybe we can make =E2=80=9Cguix environment=E2=80=9D (no argum= ents) stateful, and keep =E2=80=9Cguix environment foo bar baz=E2=80=9D stateless? > 2) Make "ad-hoc" the default. Remove the --ad-hoc flag and replace it > with a --dependencies flag instead, reversing the current behavior. > 'guix environment --dependencies guix' would create a guix dev > environment, for example. +1 > 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. > 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. Also, I would prefer the convention to be =E2=80=9C.guix.scm=E2=80=9D (to a= void confusion with the (guix) module, and to mimic existing conventions followed by Travis and all that.) Bonus: honor =E2=80=9C.guix.json=E2=80=9D (see = ) as one way to get us closer to world domination. > 5) Add support for Shepherd services. When an environment is created, > a new Shepherd process is launched to handle all the necessary > services. For a web application this could be nginx, mysql, redis, > etc. This feature can be implemented later, even post 1.0, provided > we agree upon using a record type. Yup. > After all these changes, a Guix user should be able to jump into a new > project, run 'guix environment' and be ready to go. When they update > Guix and want to refresh their environment, they would run 'guix > environment --update'. These all sound like great proposals! 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 O= K, but we should discuss it. Thank you! Ludo=E2=80=99.