From 7d3f2b99ffa8411994623f3bd32353cea63f0ecf Mon Sep 17 00:00:00 2001 From: Maxim Cournoyer Date: Tue, 17 Oct 2023 03:13:52 -0400 Subject: doc: Expound on the build-side versus host-side modules topic. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Discussed in . * doc/contributing.texi (Modules): Add new context indices, and provide a real-life counter-example, and its ramifications. Reported-by: Ludovic Courtès Change-Id: I06975fb24f0d67c833884313a727dc550f61d8a0 --- doc/contributing.texi | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) (limited to 'doc/contributing.texi') diff --git a/doc/contributing.texi b/doc/contributing.texi index 7a458903be..0d76b31c18 100644 --- a/doc/contributing.texi +++ b/doc/contributing.texi @@ -1280,11 +1280,16 @@ implement low-level concepts, such as the @code{memoize} procedure. @node Modules @subsection Modules - +@cindex build-side modules +@cindex host-side modules Guile modules that are meant to be used on the builder side must live in the @code{(guix build @dots{})} name space. They must not refer to other Guix or GNU modules. However, it is OK for a ``host-side'' module -to use a build-side module. +to use a build-side module. As an example, the @code{(guix +search-paths)} module should not be imported and used by a package since +it isn't meant to be used as a ``build-side'' module. It would also +couple the module with the package's dependency graph, which is +undesirable. Modules that deal with the broader GNU system should be in the @code{(gnu @dots{})} name space rather than @code{(guix @dots{})}. -- cgit v1.2.3