[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 'guix environment' as a build tool.
From: |
Thompson, David |
Subject: |
Re: 'guix environment' as a build tool. |
Date: |
Sun, 31 Jul 2016 10:07:00 -0400 |
On Sun, Jul 31, 2016 at 9:55 AM, Ludovic Courtès <address@hidden> wrote:
> Hello!
>
> "Thompson, David" <address@hidden> skribis:
>
>> On Sat, Jul 30, 2016 at 10:05 PM, Mathieu Lirzin <address@hidden> wrote:
>>> address@hidden (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'm sorry.
> 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.
My intention was to define it just like a regular package so that
users can do whatever they want with it: build it, install it, or make
a development environment using it.
> 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?
Hmm, that sounds like a good idea. Maybe I'll try to write a
prototype sometime. The downside of this method is that one could no
longer use the same expression as input to 'guix build -f' or 'guix
package -f'.
- Dave
- Re: [GSoC] Continuous integration tool à la Hydra., (continued)
- Re: [GSoC] Continuous integration tool à la Hydra., Ludovic Courtès, 2016/07/25
- Re: [GSoC] Continuous integration tool à la Hydra., Mathieu Lirzin, 2016/07/27
- Re: [GSoC] Continuous integration tool à la Hydra., Florian Paul Schmidt, 2016/07/29
- Re: [GSoC] Continuous integration tool à la Hydra., Mathieu Lirzin, 2016/07/29
- Re: [GSoC] Continuous integration tool à la Hydra., Ludovic Courtès, 2016/07/30
- 'guix environment' as a build tool. (was: [GSoC] Continuous integration tool à la Hydra.), Mathieu Lirzin, 2016/07/30
- Re: 'guix environment' as a build tool. (was: [GSoC] Continuous integration tool à la Hydra.), Thompson, David, 2016/07/30
- Re: 'guix environment' as a build tool., Mathieu Lirzin, 2016/07/31
- Re: 'guix environment' as a build tool., Ludovic Courtès, 2016/07/31
- Re: 'guix environment' as a build tool.,
Thompson, David <=
- Re: 'guix environment' as a build tool., Ludovic Courtès, 2016/07/31
- Re: 'guix environment' as a build tool., Ludovic Courtès, 2016/07/31
- Re: [GSoC] Continuous integration tool à la Hydra., Florian Paul Schmidt, 2016/07/31
- Re: [GSoC] Continuous integration tool à la Hydra., Mathieu Lirzin, 2016/07/31