unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Andrew Tropin <andrew@trop.in>
To: guix-devel@gnu.org
Cc: Xinglu Chen <public@yoctocell.xyz>
Subject: On the naming of System and Home services modules.
Date: Wed, 15 Sep 2021 11:47:13 +0300	[thread overview]
Message-ID: <87zgsei5ta.fsf@trop.in> (raw)

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

This topic was raised a few times during development of Guix Home
project and also during the review of wip-guix-home branch.  I made a
separate thread to do an exhaustive discussion of it.

* Services and Confusion
It's an optional section, you can skip it, but I still find it somehow
related to the topic.

I want to re-raise the issue related to system services concept.  When
I started using Guix I found system services to be confusing,
originally I thought it's a way to declare services managed by init
system, but later I realised that only some of system services becomes
Shepherd services and many of them doesn't.  It's not a unique problem
I see this issue appear again and again in different Guix chats and
communities.

- System services :: just building blocks, nodes of DAG representing
a system, which after folding, results in a complete operating system
or other artifact.
- Shepherd services :: long-living processes/daemons managed by init
system or user-space Shepherd. It's what people used to refer as services.

It will be very hard and costly to rename system services to something
less confusing, but at least let's try to keep those concepts as
distinct as possible.  Probably originally system and Shepherd
services were closely related, but not now, so let's express it very
clearly in docs/chats/mailing lists.

Another player on this field is "home services", which is a similar to
system services, but used for describing a separate DAG, which after
folding, results in home environment (artifact containing user's
program configurations and profile with packages declared by user).

* Putting Home Services to ~(gnu services ...)~
In the thread https://issues.guix.gnu.org/49419#18 Ludovic suggested:

> Regarding module names: what about putting everything in the (gnu
> home …) name space.  For services, I wonder if we could simply use
> (gnu services home), for the essential services, and other (gnu
> services …) module, but that assumes some code can be shared between
> System and Home.  Thoughts?

** Shortcomings
While it's a nice idea, I see some shortcomings here:

*** Code Reuse
Mcron, Shepherd and a few other fundamental pieces are reused between
Guix Home and Guix System, but it's easily done by exporting a few
symbols from related modules.

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

The intersection of home and system services should be very low, so
there is not much benifit here as well.

Utilitary functions like serialization helpers and so on can be
declared in a shared module and reused between System and Home
services.

Recaping the section: All the necessarry code already reused, the
future home/system services are not expected to share much code,
different utilitary functions can be shared via (gnu services utils)
or (gnu services configuration) modules.

*** Confusion
I already mentioned that I see a lot of confusion between System and
Shepherd services and I expect some confusion between home and system
services, it will be especially true if we place them in the same
namespace.

People will be trying to use home services inside operating systems,
#+begin_src scheme
(operating-system
  (services
   (list (service home-mcron-service-type ...))))
#+end_src

and configuration record for system services inside home services.
#+begin_src scheme
(home-environment
 ... (service home-mcron-service-type
              (mcron-configuration ...)))
#+end_src

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

* Putting Home Services to ~(gnu home services ...)~
Another idea I saw is to move:
~(gnu home-services)~ -> ~(gnu home services)~
~(gnu home-services gnupg)~ -> ~(gnu home services gnupg)~
...

Sounds reasonable, I'll just mention the ideas behind ~home-services~
name.

System services have following naming conventions for the public API:

in ~(gnu services CATEGORY)~ there are ~APP-service-type~,
~APP-configuration~ and other related symbols.

Not to be confused, I decided to prefix all service types and
configurations with ~home-~, so the exported symbols looks like:
~home-APP-service-type~ and ~home-APP-configuration~.

The same rule applies for module names: We do the same way as system
services do, but with ~home-~ prefix: ~(gnu services CATEGORY)~ for
system, ~(gnu home-services CATEGORY)~ for home.

All namespaces containing ~system~ now becomes ~home~: ~(gnu system)~ and
~(gnu home)~ respectively.

I find such approach to be consistent and doesn't see to much reasons
to change it.

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.

* Conclusion
I'm quite satisfied with current state of naming, but probably I miss
some points and, also, maybe there are some other good or even better
naming schemes.  In case there is a better naming approach, we can
decide on using it, It would be not an easy change, but until
wip-guix-home branch is not merged, it still easier to do this than do
it later.

LMKWYT.

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

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

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-15  8:47 Andrew Tropin [this message]
2021-09-15 10:09 ` On the naming of System and Home services modules 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
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=87zgsei5ta.fsf@trop.in \
    --to=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).