"Thompson, David" <dthomps...@worcester.edu> 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 > <guix-environment> 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 <guix-environment> 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!
