From: ludo@gnu.org (Ludovic Courtès)
To: David Craven <david@craven.ch>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: [PATCH] system: Remove spec->file-system.
Date: Mon, 05 Dec 2016 21:58:11 +0100 [thread overview]
Message-ID: <87k2beyty4.fsf@gnu.org> (raw)
In-Reply-To: <CAL1_imnihCzKRCRjMaMH6y_Z9-y0P843dewhLPuWkdyEqbZYSg@mail.gmail.com> (David Craven's message of "Sun, 4 Dec 2016 17:19:24 +0100")
Hi!
David Craven <david@craven.ch> skribis:
> Ah yes, that makes sense. Thank you for explaining. I think I'm
> understanding the general design pattern better:
>
> Build side code that uses a record from gnu/system is a gexp in
> gnu/system. This gexp is passed to a function in gnu/build so that
> gnu/build itself doesn't need to import gnu/system and can avoid
> recursive imports.
One of the goals of using Scheme on both sides is code reuse.
However, things like (guix build utils) are inherently “build side”,
hence the name. In addition, it wouldn’t make sense to pull (guix
store), (guix packages), and friends on the “build side”, because these
things cannot be used there since the build environment doesn’t give
access to the daemon (IOW, a build process cannot talk to the daemon,
it’s not recursive.)
Thus, the (guix build …) module space also serves as a way to
distinguish things and avoid pulling all of the Guix modules unwillingly
on the build side. It introduces some sort of a frontier between the
build side and the host side (info "(guix) G-Expressions").
But borders are unbearable and sometimes there’s useful stuff that we
want to use freely on both sides, like this <file-system> record type.
:-)
Ludo’.
prev parent reply other threads:[~2016-12-05 20:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-02 18:37 [PATCH] system: Remove spec->file-system David Craven
2016-12-02 23:23 ` David Craven
2016-12-04 15:48 ` Ludovic Courtès
2016-12-04 16:19 ` David Craven
2016-12-05 20:58 ` Ludovic Courtès [this message]
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=87k2beyty4.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=david@craven.ch \
--cc=guix-devel@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).