all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Andrew Tropin <andrew@trop.in>
To: "Ludovic Courtès" <ludo@gnu.org>, "Xinglu Chen" <public@yoctocell.xyz>
Cc: guix-devel@gnu.org
Subject: Re: On the naming of System and Home services modules.
Date: Fri, 24 Sep 2021 11:08:21 +0300	[thread overview]
Message-ID: <871r5eqtu2.fsf@trop.in> (raw)
In-Reply-To: <87pmsz9hrj.fsf@gnu.org>

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

On 2021-09-23 22:08, Ludovic Courtès wrote:

> Hi,
>
> Xinglu Chen <public@yoctocell.xyz> skribis:
>
>> Some services might be useful to have in both Guix System and Guix Home;
>> for instance, Guix System currently has a service for configuring
>> Syncthing, and I think it makes sense to also have one for Guix Home,
>> this would mean that people not using Guix System (me :-)) could also
>> have Guix manage Syncthing.  With the current approach, we would have to
>> copy and paste quite a bit of code, and if the Syncthing service for
>> Guix System changes, then the one for Guix Home might have to change as
>> well.
>
> Silly question, but why do we need to have two different configuration
> record types in the first place?

1. Different fields (for example system services in many cases wants to
know the username, which will be used to run process from, home services
will probably use the user's username and won't rely on this field, home
services on the other hand can have something like xdg-flavor? or
anything else unrelated to system services).

Even if fields are not conflicting with each other, it's very likely
that it will introduce a confusion: user of Guix Home on foreign distro
will be guessing why there is a field in configuration record, which
doesn't make sense for a home service.

2. Different default values.  $HOME/mail or /var/spool/mail? Even if we
can technically bypass those problems, semantically the values will be
incorrect.

There are possible solutions to that, like making home-extra-settings
and system-extra-settings fields, which will contain records with
fields, which are different for those services, but I'm not sure if all
the hussle is worth it.

>
> Sharing configuration between Home and System sounds important to me: it
> means users can easily move services from one to the other, which is
> pretty big deal.  It also means we’d have much less code to maintain.
>
> Would that be feasible?  (Apologies if this has already been discussed!)

I find records to be a very rigid and hard to reuse and probably we have
to have separate sets of configuration records as I mentioned earlier in
the thread, but the auxiliary functions seems quite reusable.

>
> Also, I proposed earlier a possible way to generate a Home service type
> from the corresponding System service type—or, IOW, to generate a Home
> service type graph from the System graph.  Does that sound feasible?

Not sure what you mean here, can you share a link to the proposal or
elaborate one more time, please.

>
> Thanks,
> Ludo’.

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

  reply	other threads:[~2021-09-24  8:09 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-15  8:47 On the naming of System and Home services modules Andrew Tropin
2021-09-15 10:09 ` Maxime Devos
2021-09-15 13:15   ` Andrew Tropin
2021-09-15 13:06 ` Xinglu Chen
2021-09-15 14:50   ` Katherine Cox-Buday
2021-09-16 10:01     ` Andrew Tropin
2021-09-16  9:57   ` Andrew Tropin
2021-09-17  9:28     ` Xinglu Chen
2021-09-17 11:35       ` Andrew Tropin
2021-09-19 14:54         ` Xinglu Chen
2021-09-23 20:08   ` Ludovic Courtès
2021-09-24  8:08     ` Andrew Tropin [this message]
2021-09-28 12:17       ` Ludovic Courtès
2021-09-24 13:35     ` Code sharing between system and home services (was Re: On the naming of System and Home services modules.) Xinglu Chen
2021-09-24 14:03       ` Maxime Devos
2021-09-24 15:39         ` Xinglu Chen
2021-09-24 17:02           ` Maxime Devos
2021-09-28 12:19           ` Ludovic Courtès
2021-09-28  6:03         ` Andrew Tropin
2021-09-24 15:32       ` Joshua Branson
2021-09-28 12:21         ` Ludovic Courtès
2021-09-29 13:52           ` Maxime Devos
2021-10-02 14:27             ` Ludovic Courtès
2021-10-02 22:13               ` Code sharing between system and home services Vagrant Cascadian
2021-10-04 14:34                 ` Ludovic Courtès
2021-10-03  8:45               ` Code sharing between system and home services (was Re: On the naming of System and Home services modules.) Maxime Devos
2021-10-04 14:32                 ` Ludovic Courtès
2021-10-04 16:14                   ` Maxime Devos
2021-10-06 13:12                     ` Ludovic Courtès
2021-09-28  2:32       ` Maxim Cournoyer
2021-09-16  3:05 ` On the naming of System and Home services modules Ryan Prior
2021-09-16  8:50   ` Andrew Tropin
2021-09-17 13:43     ` pinoaffe
2021-09-23 20:10 ` Ludovic Courtès
2021-09-28  6:32   ` Andrew Tropin
2021-09-28 12:26     ` Ludovic Courtès
2021-09-28 13:48       ` Andrew Tropin
2021-09-28 19:36         ` Oleg Pykhalov
2021-10-02 14:22           ` Ludovic Courtès
2021-10-02 17:23             ` Oleg Pykhalov
2021-09-28 15:25       ` Xinglu Chen
2021-10-02 14:25         ` Ludovic Courtès

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

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

  git send-email \
    --in-reply-to=871r5eqtu2.fsf@trop.in \
    --to=andrew@trop.in \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    --cc=public@yoctocell.xyz \
    /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 external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.