Re: 'guix environment' as a build tool.

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

Hello!

"Thompson, David" <dthompson2@worcester.edu> skribis:

> On Sat, Jul 30, 2016 at 10:05 PM, Mathieu Lirzin <mthl@gnu.org> wrote:
>> ludo@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’.