GNU bug report logs - #69587
[PATCH] doc: Add “Source Tree Structure” section.

Previous Next

Package: guix-patches;

Reported by: Ludovic Courtès <ludo <at> gnu.org>

Date: Wed, 6 Mar 2024 16:39:02 UTC

Severity: normal

Tags: patch

Done: Ludovic Courtès <ludo <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 69587 <at> debbugs.gnu.org
Subject: [bug#69587] [PATCH] doc: Add “Source Tree Structure” section.
Date: Mon, 11 Mar 2024 19:09:43 +0100
Hi Ludo.

Ludovic Courtès <ludo <at> gnu.org> writes:
>> Nice things like (guix swh) or (gnu system), (gnu build), (gnu
>> installer), (gnu machine), or po, still seem not useful for the general
>> populace to me.
>
> This is in the “Contributing” chapter, so we’re talking about a subset
> of the general populace.  :-)
>
> You might argue that few current contributors care about the modules you
> mention, but by exposing the structure of the code, my hope is that more
> people would dare take a look and fiddle with it.

Your reply makes clear that emphasis on (guix swh) was intentional.  If
SWH is central to Guix, then you are right mentioning it.  I had not
recognized and only considered it a nice, well-integrated bonus.

Still I would prefer if (gnu system), (gnu build), (gnu installer), (gnu
machine), and especially po, were not part of the list.  I expect that
most contributors want to provide a package or (home) service with docs
and tests.  They will not customize the operating-system record type.

> [...]
>
>>> The examples were meant to illustrate what is meant by “core”.  Do you
>>> think some other adjective or a longer description would help?
>>>
>>>> Perhaps (guix …) should be listed after (gnu …)  and defined as the
>>>> Guix mechanisms that do not belong in gnu?  Not quite sure either.
>>
>> Josselin called the distinction between (guix …) and (gnu …) murky,
>> explaining that most of (guix …) must not import (gnu …) except by
>> module-ref, while (guix scripts …) and such can just use-modules (gnu
>> …).  To me, gnu/packages.scm looks like core as well, but it rightfully
>> is in gnu.
>
> I think “murky” is a strong word, or at least it shouldn’t be
> interpreted as meaning that the guix/gnu distinction is arbitrary.  I’ll
> try to clarify that as well.

Hmm what is the difference between, let’s say, (gnu packages) and (guix
package)?


> @@ -638,10 +640,16 @@ Source Tree Structure
>  @end table
>  
>  The directories we have seen so far all live under @file{guix/}.  The
> -other important place is the @code{gnu/} directory, which contains
> +other important place is the @file{gnu/} directory, which contains
>  primarily package definitions as well as libraries and tools for Guix
>  System (@pxref{System Configuration}) and Guix Home (@pxref{Home
> -Configuration}).
> +Configuration}), all of which build upon functionality provided by
> +@code{(guix @dots{})} modules <at> footnote{For this reason, @code{(guix
> +@dots{})}  modules must generally not depend on @code{(gnu @dots{})}
> +modules, with one notable exception: @code{(guix build-system @dots{})}
> +modules may look up packages at run time---e.g., @code{(guix
> +build-system cmake)} needs to access the @code{cmake} variable at run
> +time.}.

I think the (guix build-system @dots{}) never use (gnu …)?  scripts and
importers do.

Regards,
Florian




This bug report was last modified 1 year and 121 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.