Hello! "Thompson, David" <dthomps...@worcester.edu> skribis:
> On Sat, Jul 30, 2016 at 10:05 PM, Mathieu Lirzin <m...@gnu.org> wrote: >> l...@gnu.org (Ludovic Courtès) writes: [...] >>> What about providing a ‘guix.scm’ file that people could pass to ‘guix >>> environment -l’ (instead of typing the long command above), and to ‘guix >>> package -f’ (info "(guix) Invoking guix package")? >> >> 'guix environment -l' uses a package definition. To me this abstraction >> doesn't fit well in a development context: > > It *does* fit well. This use-case is why I wrote 'guix environment' > in the first place. [...] >> if the user wants to enter this environment Later it will have to invoke >> './guix-env'. > > This just makes things more inconvenient and limits potential utility. That sounds harsh. I don’t have a better answer for Mathieu other than ‘guix environment -l’, and I think it does the job well. But I also think that Mathieu’s concerns must not be dismissed. For instance, it’s true that some of the metadata in ‘package’ forms looks irrelevant for the purposes of setting up a build environment—no big deal, but still it doesn’t “feel” completely right. Conversely, useful metadata is missing: for instance, I’d like to add something that would allow me to specify the equivalent of ‘--network --expose=$HOME/.gdbinit’ in development environments I use. Perhaps the solution is to introduce a new way to declare development environments? It would be similar to ‘package’, but without ‘synopsis’, ‘description’, and a couple other things; it could have additional fields to describe container setups and such likes; it would compile down to a bag, just like packages. What do you think? Thanks, Ludo’.
