Re: The future of 'guix environment'

[Ludovic Courtès]

Howdy!

"Thompson, David" <address@hidden> skribis:

> On Thu, Aug 31, 2017 at 11:16 AM, Ludovic Courtès <address@hidden> wrote:

[...]

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

Agreed, that makes sense.

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

Perfect.  So “guix environment” with no arguments would almost be a
wrapper around “guix package -p”, I think (with generations, upgrades,
etc.)

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

Oh right.  “Guixfile” then!

(Just kidding.)

Thanks!

Ludo’.