unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Xinglu Chen <public@yoctocell.xyz>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Attila Lendvai <attila@lendvai.name>,
	Maxim Cournoyer <maxim.cournoyer@gmail.com>,
	52600@debbugs.gnu.org, Andrew Tropin <andrew@trop.in>
Subject: [bug#52600] [PATCH] doc: Document (gnu services configuration).
Date: Thu, 23 Dec 2021 11:42:18 +0100	[thread overview]
Message-ID: <87ilvfd2lx.fsf@yoctocell.xyz> (raw)
In-Reply-To: <877dbwz3r7.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 2926 bytes --]

Hi,

Ludovic schrieb am Mittwoch der 22. Dezember 2021 um 23:14 +01:

> Hi,
>
> Xinglu Chen <public@yoctocell.xyz> skribis:
>
>> * guix.texi (Complex Configurations): New node.
>
> Great work!  I applied it and fixed typos Attila reported plus “bindgs”
> (instead of “bindings”).

Great, thanks for taking a look.  I didn’t receive any message from
Attila though, and there doesn’t seem to be anything on the ML either.
I guess he sent it when all the GNU infra was down, but unless he didn’t
Cc me, I don’t see why I wouldn’t receive it.

>> This patch documents the complex beast that is the (gnu services
>> configuration) module.  I only documented the things that existed before
>> the Guix Home merge, though.  There were a lot of things to document, and
>> I hope that my explanations aren’t too confusing (It took me a while to
>> wrap my head around all of this).  :-)
>
> It looks very clear to me.

Good to know.  :-)

>> What is still missing is some kind of style guide for writing Guix
>> services:  When should one use (gnu services configuration) vs plain
>> (guix records)?  Should we try to create bindings for all config options
>> or should we provide an “escape hatch” for users?
>>
>> I would personally prefer if most (if not all) services were written
>> using (gnu services configuration), but I don’t really think refactoring
>> existing services would really be worth it.  But that’s another discussion.
>
> Yeah.  So far the (unwritten) guideline has always been:
>
>   • Have record types that provide bindings for all or most of the
>     available options;
>
>   • Always provide an “escape hatch” so users can insert raw
>     configuration snippets, either because the bindings don’t cover
>     everything, or because they have an existing config file they’d like
>     to reuse.
>
> We should probably write it down somewhere.  Maybe we need a new section
> next to “Packaging Guidelines” to discuss system services?

That sounds like a good idea; Andrew started to work on something like
that[1].

> As for ‘define-configuration’ vs. (guix records) vs. SRFI-9…  I don’t
> think we really discussed the issue or agreed on something.
>
> For the rather simple services I wrote, I was happy to use plain records
> and home-made serializers rather than ‘define-configuration’.  But
> overall it seems to make more sense to recommend ‘define-configuration’
> unconditionally.  I guess it already has serializers for the most common
> formats, which are all alike, so we should be able to avoid
> boilerplate.
>
> Thoughts?

Agreed, since ‘define-configuration’ & friends are now documented, it
makes even more sense to use them.

> Thanks for substantially improving the manual!

You are welcome!  :-)

[1]: <https://yhetil.org/guix/87h7b2b6n3.fsf@trop.in/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

  reply	other threads:[~2021-12-23 10:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-18 15:12 [bug#52600] [PATCH] doc: Document (gnu services configuration) Xinglu Chen
2021-12-22 22:14 ` Ludovic Courtès
2021-12-23 10:42   ` Xinglu Chen [this message]
     [not found]     ` <IxmgfjO9lp2ladC6D9lHKww0c_r1R0JsnoPJbKD9vg1StRq5QIaZyf3If6Jc16dYnqBdbM0VAjy2PDpZBWxwhHHvgJj_lL8sE4SJ8AsG3po=@lendvai.name>
2021-12-23 12:54       ` Xinglu Chen
2021-12-23 15:21         ` Attila Lendvai
2022-01-18  9:24         ` Attila Lendvai
2022-01-06 14:20     ` Maxim Cournoyer

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=87ilvfd2lx.fsf@yoctocell.xyz \
    --to=public@yoctocell.xyz \
    --cc=52600@debbugs.gnu.org \
    --cc=andrew@trop.in \
    --cc=attila@lendvai.name \
    --cc=ludo@gnu.org \
    --cc=maxim.cournoyer@gmail.com \
    /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).