unofficial mirror of 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <>
To: Maxim Cournoyer <>
Cc: Bruno Victal <>,
Subject: Re: Divvying up service definitions
Date: Thu, 16 Nov 2023 15:49:38 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Maxim Cournoyer's message of "Tue, 07 Nov 2023 10:56:11 -0500")


Maxim Cournoyer <> skribis:

>> * Splitting this as gnu/services/dovecot.scm.
>>   We keep it compatible with 'use-service-modules' at the cost of having
>>   a multitude of files under gnu/services, without any logical grouping
>>   (messy).
> That's a great initiative!  I agree that multiple 'define-configuration'
> services per file can be a bit messy, having to use prefixes everywhere,
> making the definitions more verbose.
> I don't have a strong preference of the caterogization of services, but
> would perhaps prefer the first one (gnu/services/mail/dovecot.scm),
> which could then make it easy to offer some interface as
> gnu/services/mail.scm that'd re-export all that is needed (would that
> work, or reintroduce the same top-level clashes?).

I’m all for “cleanups” as proposed, and I don’t have strong preferences
on how to do that.

I’d like us to make sure, though, that this is made in a
backward-compatible way: these module names and exported bindings are
part of the API that users refer to from the OS config file.  Renaming
things typically breaks user config, and updating it to use the new
names can be tedious if there are no messages explaining what to do.
‘define-deprecated’ helps, but perhaps we need something a little bit
more fancy now.

(It would be great if we could reach a level of backward-compatibility
close to what Emacs does: nice deprecation messages, recording when a
particular binding was introduced, and generally changing user-visible
things rather slowly.)


      parent reply	other threads:[~2023-11-16 14:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-24 14:41 Divvying up service definitions Bruno Victal
2023-10-24 17:54 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2023-10-26 15:09   ` Bruno Victal
2023-10-28  9:11     ` Attila Lendvai
2023-11-09 14:55     ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2023-11-07 15:56 ` Maxim Cournoyer
2023-11-09  7:15   ` Efraim Flashner
2023-11-28 20:29     ` Bruno Victal
2023-12-05  1:23       ` Maxim Cournoyer
2023-11-16 14:49   ` Ludovic Courtès [this message]

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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* 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

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