Re: The future of 'guix environment'

[ludo@gnu.org (Ludovic Courtès)]

Heya,

"Thompson, David" <dthompson2@worcester.edu> 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 ‘guix environment’ would be syntactic sugar
for ‘guix package -p $PWD/.guix-environment’, right?

This would make “guix environment” stateful: if you have something in
cache, that’s what you get (it could be old versions of “foo” and
“bar”), but if you don’t, you get the current versions of “foo” and
“bar”.  Is this what you have in mind?

I prefer the current stateless behavior, whereby “guix environment
--ad-hoc foo bar” always gives you the same environment, given a Guix
commit.  But maybe we can make “guix environment” (no arguments)
stateful, and keep “guix environment foo bar baz” 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
> <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.

+1, probably with automatic conversion of <package> to <environment>, as
I wrote in another message.

> 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.

+1, except perhaps for --cache, not sure.

Also, I would prefer the convention to be “.guix.scm” (to avoid
confusion with the (guix) module, and to mimic existing conventions
followed by Travis and all that.)

Bonus: honor “.guix.json” (see <https://bugs.gnu.org/28251>) 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 <guix-environment> 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’d rather not add a new command, which means we’ll have to agree to
break the “guix environment” CLI.  I think that’s OK, but we should
discuss it.

Thank you!

Ludo’.