unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Katherine Cox-Buday <cox.katherine.e@gmail.com>
To: Xinglu Chen <public@yoctocell.xyz>
Cc: guix-devel@gnu.org, Andrew Tropin <andrew@trop.in>
Subject: Re: On the naming of System and Home services modules.
Date: Wed, 15 Sep 2021 09:50:28 -0500	[thread overview]
Message-ID: <87o88t3nbf.fsf@gmail.com> (raw)
In-Reply-To: <87pmtarnrh.fsf@yoctocell.xyz> (Xinglu Chen's message of "Wed, 15 Sep 2021 15:06:58 +0200")

Xinglu Chen <public@yoctocell.xyz> writes:

> On Wed, Sep 15 2021, Andrew Tropin wrote:

>> Records even for the same services have slightly different fields and
>> because of macro nature can't be reused between Home and System
>> services. In more details I mentioned this problem here:
>> https://lists.sr.ht/~abcdw/rde-devel/%3C87y2cqifpx.fsf%40yoctocell.xyz%3E#%3C878s4l8kai.fsf@trop.in%3E
>
> 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.

I agree with this point. I have several Guix systems, and several
non-guix systems with Guix managing some services. In the past, I have
had to write my own Shepherd services for things already written as
system services.

>> The intersection of home and system services should be very low, so
>> there is not much benifit here as well.
>
> Quite the opposite, I think it would be great if home and system
> services could integrate more with each other.  In NixOS, the NixOS
> modules and Home Manager modules feel like two very distinct things, and
> it’s not really easy to share things between them.

I agree.

>> ** Summary
>> Let's keep System and Home services separate for the sake of clarity,
>> reuse code via shared modules or just exports in (gnu services ...).

[...]

>> However, ~(gnu home services ...)~ also looks cool, but it would be a
>> little inconsistent with system services, which will have one level of
>> nestiness less: ~(gnu services)~.
>>
>> IMO, ~(gnu home services ...)~ would be a good choice if we use ~(gnu
>> system services)~ for system services.
>
> Yeah, having both (gnu system service) and (gnu home service) could make
> sense, but since we only have (gnu services), I don’t think it makes
> much sense.

I haven't put in the energy to follow the rational behind the proposed
naming schemas, but I'd like to suggest this as well: =(gnu services
home)=. This namespace increases in specificity, and I think it would
easily follow that things in =(gnu services home)= might utilize things
in =(gnu services)=. Or I also like the idea of =home= and =system=
being sibling namespaces.

-- 
Katherine


  reply	other threads:[~2021-09-15 14:54 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 [this message]
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
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

  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=87o88t3nbf.fsf@gmail.com \
    --to=cox.katherine.e@gmail.com \
    --cc=andrew@trop.in \
    --cc=guix-devel@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 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).