[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 'guix environment' as a build tool. (was: [GSoC] Continuous integrat
From: |
Thompson, David |
Subject: |
Re: 'guix environment' as a build tool. (was: [GSoC] Continuous integration tool à la Hydra.) |
Date: |
Sat, 30 Jul 2016 22:20:42 -0400 |
On Sat, Jul 30, 2016 at 10:05 PM, Mathieu Lirzin <address@hidden> wrote:
> address@hidden (Ludovic Courtès) writes:
>
>> Mathieu Lirzin <address@hidden> skribis:
>>
>>> I have tested successfully with the following command on a foreign
>>> system:
>>>
>>> guix environment --ad-hoc automake pkg-config guile guix libgcrypt sqlite
>>> guile-sqlite3
>>>
>>> Tell me if it works for you.
>>>
>>>> How about including a guix package definition then we can easily build
>>>> it assuming "we" know how to do out-of-guix-tree package building :)
>>>
>>> It would indeed be nice to provide an easy way for Guix users to install
>>> Cuirass. IMHO package definitions meant as a development build tool is
>>> confusing and should be avoided. Nonetheless, I think it is useful to
>>> document the previous 'guix environment ...' command in the README.
>>
>> 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.
> - the origin hash doesn't make sense.
You don't need one. Use local-file for the source field.
> - packages already included in Guix have redundant description and synopsis.
I don't understand what this means.
> - package definitions rely on Guix internals.
The package API rarely changes in practice.
> In fact what 'guix.scm' contains feels more like a "debian" directory or
> a "PACKAGE.spec" file on steroid because of the "guix environment -l"
> feature which derives from it but doesn't appear as first class.
>
> An idea that I like better and is less invasive, would be to complement
> bootstrap scripts with:
>
> ./bootstrap --with-guix
>
> This command would:
>
> - generate a guix-env script that wraps 'guix environment ...' if it
> doesn't exist.
> - Invoke ./guix-env
> - Invoke autoreconf -vfi
>
> 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.
You would lose the ability to tweak the dependency graph with custom
package recipes. I do this frequently in my projects that use
bleeding edge features of other software that may not even have an
official release yet. Also, with a package file, Guix users can
install the development snapshot with 'guix package -f' or simply
build it with 'guix build -f'.
> Some interesting things could be done beyond this, for example by using
> per repository profiles that would save development environments. This
> would allow developpers to easily use different setups.
'guix environment' already serves this purpose. I do want to extend
'guix environment' with a --save flag that will register the profile
it generates as a GC root so that it can be saved for future sessions
so that the environment doesn't need to be rebuilt every time the user
upgrades Guix.
Hopefully this clears things up.
- Dave
- Re: [GSoC] Continuous integration tool à la Hydra., Mathieu Lirzin, 2016/07/24
- 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 <=
- 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, 2016/07/31
- 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