From mboxrd@z Thu Jan 1 00:00:00 1970 From: iyzsong@member.fsf.org (=?utf-8?B?5a6L5paH5q2m?=) Subject: Re: The future of 'guix environment' Date: Wed, 30 Aug 2017 23:11:33 +0800 Message-ID: <87ziahytsq.fsf@member.fsf.org> References: Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58234) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dn4ek-0003Xx-59 for guix-devel@gnu.org; Wed, 30 Aug 2017 11:11:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dn4eg-0000vb-Mc for guix-devel@gnu.org; Wed, 30 Aug 2017 11:11:50 -0400 Received: from rezeros.cc ([2001:19f0:7001:2f3e:5400:ff:fe84:e55d]:40302) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dn4eg-0000u2-8l for guix-devel@gnu.org; Wed, 30 Aug 2017 11:11:46 -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 "Thompson, David" writes: > Hi all, been awhile! Yeah, glad to see you! > [...] > > 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. I always run 'guix environmeut guix' and have to wait for substitutes before entering the shell, indeed caching the environment will save me much time, but usually I don't mind that and was already used to the "awlays being latest" behaviour... I definitely want this feature too, so how about rename the current implementation of 'environment' to 'guix shell', whose ad hoc behaviour is similar to the 'nix-shell', and start a new implementation with this persistent behaviour? > > 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. > > 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. I would expect a config file is mandatory and default to something like 'environment.scm' in the current directory, and a '--config' option can be used to choose other location. This 'environment' command don't have many command line options (ad-hoc in nature), while the config file can do a lot. > > 4) Make 'guix environment' with no other args operate like 'guix > environment --cache --load=guix.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. Yeah, split them into 2 commands will be more clear :-) > > 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. Yes, maybe launch the services with a subcommand like 'guix environment up', so the shell entering 'guix environment' command can be run multiple times. > > 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'. > > Thoughts? Indeed very useful, looking forward to it!