Howdy! "Thompson, David" <[email protected]> skribis:
> On Thu, Aug 31, 2017 at 11:16 AM, Ludovic Courtès <[email protected]> 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’.
