Re: On the naming of System and Home services modules.

[Andrew Tropin <andrew@trop.in>]

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

On 2021-09-17 11:28, Xinglu Chen wrote:

> On Thu, Sep 16 2021, Andrew Tropin wrote:
>
>>>> * 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
>>>
>>> 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.
>>>
>>
>> We can extract parts, which have to be in sync between home service and
>> system service and just use them in both.  I don't see how placing home
>> service in the same module will decrease the amount of "copy-paste".
>>
>> If you talk about "shared" fields for configuration records, it's
>> probably true, but I don't see any good solution yet.  I'm unhappy that
>> records are implemented with macros, because it complicates the
>> extensibility of the mechanism, wrapping them in more macros doesn't
>> make thing better IMO.
>
> Since we don’t have a way to avoid using macros for records, resisting
> macros probably won’t really help much.  :-)
>

The fact that we already use them doesn't mean that we need to use more
macros, IMO it's a good idea to keep the amount of macros as small as
possible.

>>> I have thought about a ‘define-configuration’ macro that would
>>> generate one configuration record for Guix system and optionally,
>>> one for Guix Home.  For example
>>>
>>>   (define-configuration syncthing-configuration
>>>     ...)
>>>
>>> would work as it currently does, and
>>>
>>>   (define-configuration syncthing-configuration
>>>     ...
>>>     (home-service? #t))
>>>
>>> would generate a <syncthing-configuration> record and a
>>> <home-syncthing-configuration> record.
>>>
>>> There is the problem of <syncthing-configuration> and
>>> <home-syncthing-configuration> not having the same fields.  To solve
>>> this, Each clause could have an ‘home-service?’ field, and the code
>>> would look like
>>>
>>>   (define-configuration syncthing-configuration
>>>     (package
>>>      (package syncthing)
>>>      "Syncthing package to use.")
>>>     (arguments
>>>      (list-of-strings ’())
>>>      "Command line arguments to pass to the Syncthing package.")
>>>     (log-flags
>>>      (integer 0)
>>>      "Sum of logging flags.")
>>>     (user
>>>      (maybe-string 'disabled)
>>>      "The user as which the Syncthing service is to be run."
>>>      (home-service? #f))  ; not for Guix Home
>>>     (group
>>>      (string "users")
>>>      "The group as which the Syncthing service is to be run."
>>>      (home-service? #f))  ; likewise ^^
>>>     (home
>>>      (maybe-string 'disabled)
>>>      "Common configuration and data directory.")
>>>     (home-service? #t))
>>>
>>> This would mean that <syncthing-configuration> would have all the
>>> fields, but <home-syncthing-configuration> would have all but the ‘user’
>>> and ‘group’ fields.
>>>
>>> We could also have a ‘define-home-configuration’ macro that would create
>>> a <home-NAME-configuration> record and optionally, a
>>> <NAME-configuration> record.  Then ‘home-service?’ would be
>>> ‘system-service?’ instead.
>>>
>>> Maybe it’s too complicated and not worth it, but it’s just an idea I
>>> have had.
>>>
>>
>> define-configuration is already a quite complicated macro, but maybe
>> something like that will work, still unhappy with tons of macros for
>> implementing records in scheme (:
>>
>>>
>>>> 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.
>>
>> The system and home services can't really integrate with each other at
>> least because of extension mechanism.
>>
>>> 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.
>>>
>>
>> Yes, but with Guix System and Guix Home it's easier to keep them in sync
>> and share code between them because they are both a part of the same
>> repo.
>>
>> Going back to intersection: Yes, there are some services that are common
>> to Guix Home and System: mcron, shepherd and maybe a few more, but most
>> of the `guix system search .` is not relevant for user.
>>
>> Everything that can be implemented as a home service should implement
>> as a home service in most cases.
>
> Not really sure what you mean by this, but the above proposal would
> create a <NAME-configuration> and a <home-NAME-configuration> record.

If something can be both home and system service we can prefer to
implement home service, because it can be used on both Guix System and
foreign distros.

Yes, I got your idea.

>> There are two case, where you can bring an argument against it, but
>> I'll propose solutions upfront:
>>
>> - As admin I want to add a service in operating-system, but it's only
>>   available as a home service.
>>
>> I think we can do something like that:  
>>
>> #+begin_src scheme
>> (operating-system
>>   (services
>>    (list (service guix-home
>>                   `(("USERNAME1" ,(generate-home-environment
>>                                    with-needed-services)))))))
>> #+end_src
>>
>> - I want to start the home service on boot.
>>
>> Probably, something like linger systemd will be needed here for
>> Shepherd, still seems very possible to implement.
>> https://www.freedesktop.org/software/systemd/man/loginctl.html#enable-linger%20USER%E2%80%A6
>
> That would be nice to have.
>
>> Yes, probably there are cases where we will need to have both system
>> and home services, but I expect this number to be very low and
>> everything else will fall in one category of services, this is what I
>> mean by small intersection.  As an exercise try to name 10 services,
>> which doesn't belong to only one category.
>
> Well, there are quite a few that I can think of
>
> * The ones we have already mentioned: Mcron, Shepherd, and Syncthing.
>
> * Unattended-upgrade.
>
> * Rsync/state management.
>
> * guix-publish: As a normal user, I should be able to run a ‘guix
>   publish’ service, to share substitutes with others, without needing
>   root access.
>
> * Mail related services: Getmail/Fetchmail/Isync can be used by a normal
>   user for fetching their mail from some remote server.  These programs
>   can also be used by a server that hosts a Patchwork instance to track
>   patches sent to a mailing list.  I think this is what Christopher’s
>   Patchwork instance does.
>
>     <https://patches.guix-patches.cbaines.net/project/guix-patches/list/>
>
>   Dovecot/OpenSMTP/Exim can be used on a mail server, but they can also
>   be used as a local IMAP server, which something like Gnus can connect
>   to.
>
>   I have also seen people use Postfix as a Sendmail/Msmtp replacement,
>   and it would thus make sense to have a Guix Home service for it too.
>
> * Alsa: There is already an Alsa service for Guix System, but a user may
>   also want like to configure their ~/.asoundrc file in order to not
>   pollute the system configuration.
>
> * WeeChat can be used as an IRC client, and as a relay for other WeeChat
>   clients to connect to.  It would therefore make sense to have WeeChat
>   running on a server (Guix System), and then connect to it through
>   WeeChat as a regular user (Guix Home).
>
> * Shells: Each individual user will most likely configure their shell,
>   but the sysadmin also might want the configure the system-wide shell
>   and not just run with the default settings.
>
> There is also the problem of system service only working on Guix System,
> whereas home services will work on foreign distros as well.  As someone
> who is on a foreign distro, I would like to configure things like Tor
> (and Privoxy), Transmission, Ipfs, Bitlbee, and a login manager and a
> desktop environment.  But right now I have to be on Guix System to
> configure to these things.
>
> That’s just the ones I can think of; other people probably have more
> things to add.
>

I think most of this usecases are solvable by having only home services
and linger shepherd.

For example an administrator can define a home-environment in
operating-system for weechat-relay user, which contains a WeeChat home
service, configured as a relay and setup it with `guix system
reconfigure`.  Any other users can control their own home-environments
and configure and install their weechat clients with `guix home`

I see the downside that such processes won't be visible in root's herd,
but as I already mentioned it doesn't seems to be a big problem and in
addition, it is most likely solvable.

>>> A while ago, someone on IRC mentioned that it would be nice to have
>>> Mcron in Guix System run Mcron jobs that were specified in Guix Home.
>>> The rationale is that Guix Home for a user will not activate---run
>>> user Shepherd, thus running Mcron---until that user logs in.  This
>>> means that Bob’s Mcron jobs will only run when Bob is logged in.  The
>>> Mcron jobs in specified in Guix System will run regardless if the user
>>> that those jobs belong to logs in.  But if Bob wants their Mcron jobs
>>> to run regardless if he logs in, he needs root access to be able to
>>> add jobs to his Guix System config and run ‘guix system reconfigure’.
>>> This does mean that the sysadmin has to add ‘mcron-service-type’ to
>>> the ‘services’ field of the <operating-system> record, though.
>>>
>>
>> Covered by linger idea mentioned above.  The downside is it won't be
>> visible in root's herd cli, but it also fixable either by extending
>> shepherd or by using su to run herd from specific user.
>>
>>>> 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
>>>
>>> With the above proposal, the user would use ‘home-mcron-configuration’
>>> for home service, so I don’t think this should be a problem.  And as
>>> Maxime mentioned, we could have a ‘validate’ field which would give a
>>> friendly error message if the wrong configuration record was given.
>>>
>>>> ** 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.
>>>
>>> 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.
>>>
>>
>> Just to clarify, by ..., I meant submodules, so it will be
>> (gnu system services version-control) and
>> (gnu home services version-control) for example.
>
> Sorry, I forgot to add ...; I meant (gnu system services ...) and (gnu
> home services ...).
>
>> For now it's just:
>> (gnu services version-control) and
>> (gnu home-services version-control), which I find okeish.
>
> I would prefer to just have everything verson-control-related in (gnu
> service version-control).  Since everything is prefixed with ‘home-’, it
> should make things clear that its used by Guix Home and not Guix System.

Ok, got your opinion.

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