From: "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 69587@debbugs.gnu.org
Subject: [bug#69587] [PATCH] doc: Add “Source Tree Structure” section.
Date: Mon, 11 Mar 2024 19:09:43 +0100 [thread overview]
Message-ID: <87jzm8prmg.fsf@pelzflorian.de> (raw)
In-Reply-To: <87le6oog1j.fsf@gnu.org> ("Ludovic Courtès"'s message of "Mon, 11 Mar 2024 18:05:12 +0100")
Hi Ludo.
Ludovic Courtès <ludo@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@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
next prev parent reply other threads:[~2024-03-11 18:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-06 16:37 [bug#69587] [PATCH] doc: Add “Source Tree Structure” section Ludovic Courtès
2024-03-08 18:01 ` pelzflorian (Florian Pelz)
2024-03-08 22:06 ` Ludovic Courtès
2024-03-09 14:38 ` pelzflorian (Florian Pelz)
2024-03-11 17:05 ` Ludovic Courtès
2024-03-11 18:09 ` pelzflorian (Florian Pelz) [this message]
2024-03-13 21:45 ` Ludovic Courtès
2024-03-14 11:30 ` pelzflorian (Florian Pelz)
2024-03-19 14:16 ` Ludovic Courtès
2024-03-20 10:49 ` [bug#69587] [PATCH v2] " Ludovic Courtès
2024-03-20 17:05 ` pelzflorian (Florian Pelz)
2024-03-21 16:49 ` bug#69587: " Ludovic Courtès
2024-03-12 16:35 ` [bug#69587] [PATCH] " Giovanni Biscuolo
2024-03-12 18:41 ` pelzflorian (Florian Pelz)
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=87jzm8prmg.fsf@pelzflorian.de \
--to=pelzflorian@pelzflorian.de \
--cc=69587@debbugs.gnu.org \
--cc=ludo@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).