[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 'guix environment' as a build tool.
From: |
Mathieu Lirzin |
Subject: |
Re: 'guix environment' as a build tool. |
Date: |
Sun, 31 Jul 2016 06:17:08 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
"Thompson, David" <address@hidden> writes:
> 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.
Obviously I disagree.
>> - the origin hash doesn't make sense.
>
> You don't need one. Use local-file for the source field.
I would be happy to, however I vaguely remember trying this without
success for Mcron. Do you have an example to provide?
>> - 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.
This is relative, IME packages moving across modules is not an
exception.
>> 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.
Since this script is supposed to be wrapper around 'guix environment' I
don't understand how it could limit anything 'guix environment' could
do?
> Also, with a package file, Guix users can install the development
> snapshot with 'guix package -f' or simply build it with 'guix build
> -f'.
I am not sure what you mean by "development snapshot". If you an
arbitrary timely chosen commit like what is done for Haunt:
(origin
(method git-fetch)
(uri (git-reference
(url "git://dthompson.us/haunt.git")
(commit "f0a7c2b14a201448432d3564d851ee0686d5b1b1")))
(sha256
(base32
"1dnzsw18blhr8admw48zbl3ilz3iiqmb149i37y820h0imqfli0v"))))
This is not useful for me. In most case I want 'guix build -f' to build
the current commit from the local repository. If 'local-file' can work
then this is fine, but I have never achieved the expected result.
>> 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.
That would be nice.
> Hopefully this clears things up
Maybe I am misinterpreting, but this read a bit patronizing. No need to
say that if this is the case I don't appreciate much.
--
Mathieu Lirzin
- 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, 2016/07/30
- Re: 'guix environment' as a build tool.,
Mathieu Lirzin <=
- 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