all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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’.

      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

* 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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.