unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Mathieu Lirzin <mthl@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: 'guix environment' as a build tool.
Date: Sun, 31 Jul 2016 13:13:53 +0200	[thread overview]
Message-ID: <87r3aa6owe.fsf@gnu.org> (raw)
In-Reply-To: <877fc2k1ei.fsf_-_@gnu.org> (Mathieu Lirzin's message of "Sun, 31 Jul 2016 04:05:25 +0200")

Hello,

Mathieu Lirzin <mthl@gnu.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mathieu Lirzin <mthl@gnu.org> 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:
>
>  - the origin hash doesn't make sense.

Not a problem with ‘local-file’, as David wrote.

>  - packages already included in Guix have redundant description and synopsis.

Yeah, though for such packages, a guix.scm is typically less useful
since most of the time ‘guix environment PACKAGE’ is enough.

>  - package definitions rely on Guix internals.

I sympathize both with this and with what David wrote here.

I can sympathize with the idea that conceptually a package definition is
not quite the same thing as a development environment definition, in
practice ‘guix environment -l’ remains much better than the long command
line above.  :-)

> 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'.

I’m not convinced by generated scripts.

Now, we’re at a stage where everyone is welcome to explore their own
way.  Some may prefer a ‘guix.scm’ file, while others would prefer a
script that runs ‘guix environment --ad-hoc’.  With more experience,
maybe we can come up with a solution that better caters to everyone’s
needs.

Thanks,
Ludo’.

  parent reply	other threads:[~2016-07-31 11:14 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-29 20:10 [GSoC] Continuous integration tool à la Hydra Mathieu Lirzin
2016-05-30 21:34 ` Ludovic Courtès
2016-05-30 21:54 ` Ludovic Courtès
2016-06-20 22:44 ` Mathieu Lirzin
2016-06-24 12:42   ` Ludovic Courtès
2016-07-25  0:30 ` Mathieu Lirzin
2016-07-25 21:36   ` Ludovic Courtès
2016-07-27 14:28     ` Mathieu Lirzin
2016-07-28 12:38       ` Ludovic Courtès
2016-07-29 11:20     ` Florian Paul Schmidt
2016-07-29 19:26       ` Mathieu Lirzin
2016-07-30 22:49         ` Ludovic Courtès
2016-07-31  2:05           ` 'guix environment' as a build tool. (was: [GSoC] Continuous integration tool à la Hydra.) Mathieu Lirzin
2016-07-31  2:20             ` Thompson, David
2016-07-31  4:17               ` 'guix environment' as a build tool Mathieu Lirzin
2016-07-31 13:55               ` Ludovic Courtès
2016-07-31 14:07                 ` Thompson, David
2016-07-31 20:09                   ` Ludovic Courtès
2016-07-31 11:13             ` Ludovic Courtès [this message]
2016-07-31  7:09         ` [GSoC] Continuous integration tool à la Hydra Florian Paul Schmidt
2016-07-31 12:03           ` Mathieu Lirzin
2016-08-01 18:55             ` Florian Paul Schmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r3aa6owe.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=mthl@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).