From: Andrew Tropin <andrew@trop.in>
To: Katherine Cox-Buday <cox.katherine.e@gmail.com>,
Xinglu Chen <public@yoctocell.xyz>
Cc: guix-devel@gnu.org
Subject: Re: On the naming of System and Home services modules.
Date: Thu, 16 Sep 2021 13:01:09 +0300 [thread overview]
Message-ID: <87wnngx2je.fsf@trop.in> (raw)
In-Reply-To: <87o88t3nbf.fsf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2919 bytes --]
On 2021-09-15 09:50, Katherine Cox-Buday wrote:
> 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.
>
Shouldn't be a problem, if home service will be a prefered option.
More details on that in the reply to Xinglu, look for linger keyword.
>
>>> 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.
Actually a good idea, thank you, I will consider it.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2021-09-16 10:03 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 [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wnngx2je.fsf@trop.in \
--to=andrew@trop.in \
--cc=cox.katherine.e@gmail.com \
--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 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.