Re: The future of 'guix environment'

[iyzsong@member.fsf.org (宋文武)]

"Thompson, David" <dthompson2@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!