unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de>
Cc: 69587@debbugs.gnu.org
Subject: [bug#69587] [PATCH] doc: Add “Source Tree Structure” section.
Date: Wed, 13 Mar 2024 22:45:01 +0100	[thread overview]
Message-ID: <877ci5iz6q.fsf@gnu.org> (raw)
In-Reply-To: <87jzm8prmg.fsf@pelzflorian.de> (pelzflorian@pelzflorian.de's message of "Mon, 11 Mar 2024 19:09:43 +0100")

Hello,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

> 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.

[...]

> 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.

I disagree here.  This section is intended for people willing to
contribute to Guix or to learn about it beyond packages (perhaps that
intention should be more clearly stated though; perhaps that’s the crux
of our difference of interpretation?).  I wouldn’t assume that this or
that part is not worthy.

If the section is deemed too long, it probably makes sense to trim it a
bit, but I don’t find it this long.

Or we can use different examples, though I would keep those that are
already documented elsewhere in the manual (like (gnu system)).

WDYT?

>> 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)?

(guix packages) defines a <package> type and associated mechanisms (the
“package Reference” section).

(gnu packages) lets you browse packages defined in (gnu packages …),
etc.

The former is abstract; the latter is about concrete package
definitions.

>> +@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 …)?

They do, as in the ‘cmake’ example above.

> scripts and importers do.

Oh right, that’s true.  So there’s more than one notable exception.  :-)

Ludo’.




  reply	other threads:[~2024-03-13 21:46 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)
2024-03-13 21:45           ` Ludovic Courtès [this message]
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=877ci5iz6q.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=69587@debbugs.gnu.org \
    --cc=pelzflorian@pelzflorian.de \
    /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).