Re: The future of 'guix environment'

["Thompson, David" <dthompson2@worcester.edu>]

On Thu, Aug 31, 2017 at 11:16 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> 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?

Yeah, I guess so.  I've never used the -p flag and don't know if it
should stay.  I'll try to preserve it and see how that goes!

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

Yes. For regularly hacked on project environments I think this is the
most useful behavior.  Because then, much like my regular user
profile, I can update at a time when I feel ready to do so, rather the
current situation where I'm forced to rebuild and deal with potential
breakage or long download/compile times.

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

That's what I had in mind.  In my head there's two important cases:
the on-the-fly, stateless environment, and the persistent environment
that you update every now and then when you feel like living on the
edge.  'guix environment foo bar' (ad-hoc being the new default)
should absolutely be stateless, just like it is now.

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

Ah, this is a clever hack!  I will do that.  Thanks for suggesting it.

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

I think I will convince you it's a good idea. ;)

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

Sure, that's fine with me, but FYI there are existing conventions of
using non-hidden files. Bundler uses 'Gemfile', Docker uses
'Dockerfile', Vagrant uses 'Vagrantfile', npm uses 'package.json',
etc.

> Bonus: honor “.guix.json” (see <https://bugs.gnu.org/28251>) as one way
> to get us closer to world domination.

Maybe someone else can add that after I do everything else. :)

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

I agree.  We can discuss more when I have patches.  I will probably
have additional questions as I go.  The biggest unknown for me so far
is how environment profile generation management will work (if it
should even exist), but I'll get the basics sorted out first.

Thanks for your feedback!

- Dave