On the naming of System and Home services modules.

On the naming of System and Home services modules.

[Andrew Tropin]

[-- 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 --]

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

[Maxime Devos]

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

Andrew Tropin schreef op wo 15-09-2021 om 11:47 [+0300]:
> *** 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

What do you think of adding some validation code to 'service-type'
and the "guix home" equivalent, e.g. a ‘validate’ field, which
could be used like

(define-module (...)
  #:autoload (gnu home??? mcron) (mcron-user-configuration?))

(define mcron-service-type
  (service-type (name 'mcron)
                ...
                (validate
                  (lambda (config)
                    (cond ((mcron-configuration? config) #t)
                          ((home-mcron-configuration? config)
                           ;; TODO: figure out a clear error message
                           (validation-error (G_ "A mcron configuration for the system was expected, but a configuration for the user was used")))
                          (#t #f))))))

and likewise for the "guix home" equivalent, such that if user configurations
are used in the system configuration, an error message is printed, indicating
the issue?  Maybe include the line and column number of the record as well.

Greetiings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

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

[Andrew Tropin]

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

On 2021-09-15 12:09, Maxime Devos wrote:

> Andrew Tropin schreef op wo 15-09-2021 om 11:47 [+0300]:
>> *** 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
>
> What do you think of adding some validation code to 'service-type'
> and the "guix home" equivalent, e.g. a ‘validate’ field, which
> could be used like
>
> (define-module (...)
>   #:autoload (gnu home??? mcron) (mcron-user-configuration?))
>
> (define mcron-service-type
>   (service-type (name 'mcron)
>                 ...
>                 (validate
>                   (lambda (config)
>                     (cond ((mcron-configuration? config) #t)
>                           ((home-mcron-configuration? config)
>                            ;; TODO: figure out a clear error message
>                            (validation-error (G_ "A mcron configuration for the system was expected, but a configuration for the user was used")))
>                           (#t #f))))))
>
> and likewise for the "guix home" equivalent, such that if user configurations
> are used in the system configuration, an error message is printed, indicating
> the issue?  Maybe include the line and column number of the record as well.
>
> Greetiings,
> Maxime.

Hi Maxime,

Nice idea and viable solution, but here I was talking about the case,
when both home-mcron-service-type and mcron-service-type in the same
(gnu services mcron) namespace.  I expect much less confusion and it
probably won't be an issue, when they are in different modules (gnu
home-services mcron) and (gnu services mcron) for example.  If person
imports (gnu services SOMETHING) than they expect to get system services
for their operating-system, if they imports (gnu home-services
SOMETHING) they want to extend their home-environment. 

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

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

[Xinglu Chen]

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

On Wed, Sep 15 2021, Andrew Tropin wrote:

> 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

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

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

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.

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

> * 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: 861 bytes --]

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

[Katherine Cox-Buday]

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

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

[Andrew Tropin]

[-- 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 --]

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

[Andrew Tropin]

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

On 2021-09-15 15:06, Xinglu Chen wrote:

> On Wed, Sep 15 2021, Andrew Tropin wrote:
>
>> 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
>
> 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.

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

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


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.

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

For now it's just:
(gnu services version-control) and
(gnu home-services version-control), which I find okeish.

>
>> * 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 --]

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

[Xinglu Chen]

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

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

>> 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.
There would then be a ‘NAME-service-type’ and a
‘home-NAME-service-type’.

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

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

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

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

[Andrew Tropin]

[-- 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 --]

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

[Xinglu Chen]

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

On Fri, Sep 17 2021, Andrew Tropin wrote:

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

That could work, but a lot of problems/questions would also pop up; see
some examples below.

> 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`

That could work, then one would have to have lots of home environments
if they had many services.  Having a bunch of home environment would
probably introduce quite a bit of overhead, compared to just running a
service as another user.  The configuration would also be quite a bit
more complicated; instead of something like this:

  (operating-system
    (services (list (service dovecot-service-type ...)
                    (service tor-service-type ...)
                    (service weechat-service-type ...))))

It would look something like:

  
  (operating-system
    (services (list (service guix-home
                             `(("dovecot" ,(generate-home-environment ...))
                               ("tor" , (generate-home-environment ...))
                               ("weechat" ,(generate-home-environment ...)))))))

And the user would also have to manually create the “dovecot”, “tor”,
and “weechat” users and groups by extending the ‘account-service-type’.

These services would also start on boot regardless if there is any
internet connection, because the Shepherd for the “dovecot” user isn’t
aware of the networking ‘requirement’, which is only available for Guix
System services.

There is also the problem of what if the Dovecot service, which is a
home service, has to extend something that is not a home service, e.g.,
‘etc-service-type’ or ‘pam-root-service-type’?  ‘home-file-service-type’
can only create files in $HOME of the user, but a file might have to be
put somewhere in /etc, which is out of reach of ‘home-file-service-type’
for the “dovecot” user.

By having a bunch of home-services, something like ‘guix system
extension-graph’ and ‘guix system shepherd-graph’ would be a lot less
useful, since a lot of things would be in home environments.  It would
make it harder for the user to visualize and understand how the system
is built from all of these system services and home-service.

If the Dovecot service became a home service, it would break
backwards-compatiblity and break many peoples setups.


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

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

[Ludovic Courtès]

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?

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!)

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?

Thanks,
Ludo’.

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

[Andrew Tropin]

[-- 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 --]

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

[Ludovic Courtès]

Hi Andrew,

Andrew Tropin <andrew@trop.in> skribis:

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

[...]

>> Silly question, but why do we need to have two different configuration
>> record types in the first place?

To be clear: you’ll have to be very convincing as I know all too well
the cost of maintaining such a thing :-) and can already foresee that
this would also be annoying to users.

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

Do you have specific examples?  The user name example isn’t a convincing
one for me, at least not in the abstract.

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

Again, any specific example?  How frequently does this problem occur?

It could be solved, say, by having a ‘home-service?’ Boolean in the
config, which default values would take into account.

>> 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

We can discuss the suitability of records, but we need an immediate
solution to the problem, especially now that it’s in ‘master’.

Duplicating configuration records for each and every service could have
a huge maintenance cost that we’re probably not willing to pay.

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

I can’t find the message anymore.  The suggestion is to have helpers to
“rewrite” the System service type graph for Home, so you could do things
like:

  (define home-profile-service-type
    (system->home-service-type profile-service-type))

  (define home-mcron-service-type
    (system->home-service-type mcron-service-type))

because fundamentally, these two things are the same as their System
counterpart, except that they graph is rooted in ‘home-service-type’ (or
whatever it’s called) instead of ‘system-service-type’.

Of course there are exceptions, but it may be possible to do that for
quite a few services.

Thoughts?

Ludo’.

Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Xinglu Chen]

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

On Thu, Sep 23 2021, 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?

The problem is that the configuration records for system and home
service don’t necessarily have the same fields.  The Syncthing service
for Guix System has a ‘user’ and a ‘group’ field, which is not really of
any use in Guix Home, as the only user would be the user invoking ‘guix
home’.

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

Agreed, that’s what I would like to see as well.

> Would that be feasible?  (Apologies if this has already been
> discussed!)

Since it might not make sense to have the same records fields for a
system service and home service, I proposed (in the mail you replied to)
a ‘define-configuration’ form that would generate a configuration record
for a system service and optionally one for a home service, without
having to maintain two records separately.

--8<---------------cut here---------------start------------->8---
(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))
--8<---------------cut here---------------end--------------->8---

It would generate <syncthing-configuration> and
<home-syncthing-configuration>.  The only difference being that
<home-syncthing-configuration> doesn’t have a ‘user’ and a ‘group’
field.

It’s probably going to be quite complicated, so it would be good to get
some feedback/thoughts on it.  Cc Maxim since he has done some work with
(gnu services configuration).

Also, it’s probably time to properly document (gnu services
configuration) in the manual.  ;-)

> 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?

I am not sure exactly what you mean here, could you elaborate?


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

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Maxime Devos]

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

Xinglu Chen schreef op vr 24-09-2021 om 15:35 [+0200]:
> On Thu, Sep 23 2021, 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?
> 
> The problem is that the configuration records for system and home
> service don’t necessarily have the same fields.  The Syncthing service
> for Guix System has a ‘user’ and a ‘group’ field, which is not really of
> any use in Guix Home, as the only user would be the user invoking ‘guix
> home’.
> 
> > 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.
> 
> Agreed, that’s what I would like to see as well.
> 
> > Would that be feasible?  (Apologies if this has already been
> > discussed!)
> 
> Since it might not make sense to have the same records fields for a
> system service and home service, I proposed (in the mail you replied to)
> a ‘define-configuration’ form that would generate a configuration record
> for a system service and optionally one for a home service, without
> having to maintain two records separately.
> 
> --8<---------------cut here---------------start------------->8---
> (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))
> --8<---------------cut here---------------end--------------->8---
> 
> It would generate <syncthing-configuration> and
> <home-syncthing-configuration>.  The only difference being that
> <home-syncthing-configuration> doesn’t have a ‘user’ and a ‘group’
> field.

The 'parent' mechanism (rnrs records syntactic) 'parent' could be used
here (after adapting it to define-configuration), to define three record types:

The record type with all fields common to the home configuration and system configuration
(<common-syncthing-configuration> + common-syncthing-configuration?)
and the record types for the home and system configuration
(<syncthing-configuration> + syncthing-configuration? and <home-syncthing-configuration>
+ home-syncthing-configuration?).

Using this mechanism, all syncthing-configuration? and home-syncthing-configuration?
are common-syncthing-configuration?.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Xinglu Chen]

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

On Fri, Sep 24 2021, Maxime Devos wrote:

> Xinglu Chen schreef op vr 24-09-2021 om 15:35 [+0200]:
>> On Thu, Sep 23 2021, 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?
>> 
>> The problem is that the configuration records for system and home
>> service don’t necessarily have the same fields.  The Syncthing service
>> for Guix System has a ‘user’ and a ‘group’ field, which is not really of
>> any use in Guix Home, as the only user would be the user invoking ‘guix
>> home’.
>> 
>> > 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.
>> 
>> Agreed, that’s what I would like to see as well.
>> 
>> > Would that be feasible?  (Apologies if this has already been
>> > discussed!)
>> 
>> Since it might not make sense to have the same records fields for a
>> system service and home service, I proposed (in the mail you replied to)
>> a ‘define-configuration’ form that would generate a configuration record
>> for a system service and optionally one for a home service, without
>> having to maintain two records separately.
>> 
>> --8<---------------cut here---------------start------------->8---
>> (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))
>> --8<---------------cut here---------------end--------------->8---
>> 
>> It would generate <syncthing-configuration> and
>> <home-syncthing-configuration>.  The only difference being that
>> <home-syncthing-configuration> doesn’t have a ‘user’ and a ‘group’
>> field.
>
> The 'parent' mechanism (rnrs records syntactic) 'parent' could be used
> here (after adapting it to define-configuration), to define three record types:
>
> The record type with all fields common to the home configuration and system configuration
> (<common-syncthing-configuration> + common-syncthing-configuration?)
> and the record types for the home and system configuration
> (<syncthing-configuration> + syncthing-configuration? and <home-syncthing-configuration>
> + home-syncthing-configuration?).
>
> Using this mechanism, all syncthing-configuration? and home-syncthing-configuration?
> are common-syncthing-configuration?.

I didn’t know about the parent mechanism; that could be an approach to
take.  But since ‘define-configuration’ is based on (guix records),
would it make sense to adapt (guix records) to (rnrs records syntactic)
instead of SRFI-9 records?


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

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Maxime Devos]

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

Xinglu Chen schreef op vr 24-09-2021 om 17:39 [+0200]:
> 
[...]
> I didn’t know about the parent mechanism; that could be an approach to
> take.  But since ‘define-configuration’ is based on (guix records),
> would it make sense to adapt (guix records) to (rnrs records syntactic)
> instead of SRFI-9 records?

(rnrs records syntactic) or the underlying mechanism for (srfi srfi-9) and
(rnrs records syntactic) (search for record-modifier in the guile manual).

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Ludovic Courtès]

Hi,

Xinglu Chen <public@yoctocell.xyz> skribis:

> I didn’t know about the parent mechanism; that could be an approach to
> take.  But since ‘define-configuration’ is based on (guix records),
> would it make sense to adapt (guix records) to (rnrs records syntactic)
> instead of SRFI-9 records?

Yes, it would make sense (using the lower-level record API, as Maxime
writes), and it’d be useful in other situations as well.

I can take a look if nobody beats me.

Thanks,
Ludo’.

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Andrew Tropin]

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

On 2021-09-24 16:03, Maxime Devos wrote:

> Xinglu Chen schreef op vr 24-09-2021 om 15:35 [+0200]:
>> On Thu, Sep 23 2021, 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?
>> 
>> The problem is that the configuration records for system and home
>> service don’t necessarily have the same fields.  The Syncthing service
>> for Guix System has a ‘user’ and a ‘group’ field, which is not really of
>> any use in Guix Home, as the only user would be the user invoking ‘guix
>> home’.
>> 
>> > 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.
>> 
>> Agreed, that’s what I would like to see as well.
>> 
>> > Would that be feasible?  (Apologies if this has already been
>> > discussed!)
>> 
>> Since it might not make sense to have the same records fields for a
>> system service and home service, I proposed (in the mail you replied to)
>> a ‘define-configuration’ form that would generate a configuration record
>> for a system service and optionally one for a home service, without
>> having to maintain two records separately.
>> 
>> --8<---------------cut here---------------start------------->8---
>> (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))
>> --8<---------------cut here---------------end--------------->8---
>> 
>> It would generate <syncthing-configuration> and
>> <home-syncthing-configuration>.  The only difference being that
>> <home-syncthing-configuration> doesn’t have a ‘user’ and a ‘group’
>> field.
>
> The 'parent' mechanism (rnrs records syntactic) 'parent' could be used
> here (after adapting it to define-configuration), to define three record types:
>
> The record type with all fields common to the home configuration and system configuration
> (<common-syncthing-configuration> + common-syncthing-configuration?)
> and the record types for the home and system configuration
> (<syncthing-configuration> + syncthing-configuration? and <home-syncthing-configuration>
> + home-syncthing-configuration?).
>
> Using this mechanism, all syncthing-configuration? and home-syncthing-configuration?
> are common-syncthing-configuration?.
>
> Greetings,
> Maxime.

It can work.  Good idea.

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

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Joshua Branson]

Xinglu Chen <public@yoctocell.xyz> writes:

> On Thu, Sep 23 2021, 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?
>
> The problem is that the configuration records for system and home
> service don’t necessarily have the same fields.  The Syncthing service
> for Guix System has a ‘user’ and a ‘group’ field, which is not really of
> any use in Guix Home, as the only user would be the user invoking ‘guix
> home’.

Apologies if I'm speaking for something I know very little
about...Wouldn't it be nice if guix home services would accept a user
and a group field?  For the syncthing service, perhaps the user wants to
limit Syncthing's runtime permissions.  So instead of running as the
user, the user would run synthing as a different user with less permissions?

Please note it may be much better to just container-ize the synthing
service.  Does guix home have that ability?

https://guix.gnu.org/en/blog/2017/running-system-services-in-containers/

>
>> 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.
>
> Agreed, that’s what I would like to see as well.
>
>> Would that be feasible?  (Apologies if this has already been
>> discussed!)
>
> Since it might not make sense to have the same records fields for a
> system service and home service, I proposed (in the mail you replied to)
> a ‘define-configuration’ form that would generate a configuration record
> for a system service and optionally one for a home service, without
> having to maintain two records separately.
>
> (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))
>
> It would generate <syncthing-configuration> and
> <home-syncthing-configuration>.  The only difference being that
> <home-syncthing-configuration> doesn’t have a ‘user’ and a ‘group’
> field.
>
> It’s probably going to be quite complicated, so it would be good to get
> some feedback/thoughts on it.  Cc Maxim since he has done some work with
> (gnu services configuration).
>
> Also, it’s probably time to properly document (gnu services
> configuration) in the manual.  ;-)
>
>> 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?
>
> I am not sure exactly what you mean here, could you elaborate?
>

-- 
Joshua Branson (jab in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar
  

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Ludovic Courtès]

Hi,

Joshua Branson <jbranso@dismail.de> skribis:

> Apologies if I'm speaking for something I know very little
> about...Wouldn't it be nice if guix home services would accept a user
> and a group field?  For the syncthing service, perhaps the user wants to
> limit Syncthing's runtime permissions.  So instead of running as the
> user, the user would run synthing as a different user with less permissions?

That’s not possible unless the calling user is root, since you’d need
the ability to switch users somehow.

> Please note it may be much better to just container-ize the synthing
> service.  Does guix home have that ability?
>
> https://guix.gnu.org/en/blog/2017/running-system-services-in-containers/

It can gain that availability without doing anything actually: service
implementations “just” need to use ‘make-forkexec-constructor/container’
instead of ‘make-forkexec-constructor’.

However, that would only work on systems where unprivileged user
namespaces are enabled, so we’d need a way to turn it off.

Ludo’.

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Maxime Devos]

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

Ludovic Courtès schreef op di 28-09-2021 om 14:21 [+0200]:
> Hi,
> 
> Joshua Branson <jbranso@dismail.de> skribis:
> 
> > Apologies if I'm speaking for something I know very little
> > about...Wouldn't it be nice if guix home services would accept a user
> > and a group field?  For the syncthing service, perhaps the user wants to
> > limit Syncthing's runtime permissions.  So instead of running as the
> > user, the user would run synthing as a different user with less permissions?
> 
> That’s not possible unless the calling user is root, since you’d need
> the ability to switch users somehow.

On Debian, a user has a list of ‘subordinate user IDs’ which can be switched
to without root: <https://manpages.debian.org/buster/uidmap/newuidmap.1.en.html>.

Maybe "guix home" could use that mechanism, and this mechanism could be implemented
on Guix System as well?

Greetings,
Maxime

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Ludovic Courtès]

Maxime Devos <maximedevos@telenet.be> skribis:

> Ludovic Courtès schreef op di 28-09-2021 om 14:21 [+0200]:
>> Hi,
>> 
>> Joshua Branson <jbranso@dismail.de> skribis:
>> 
>> > Apologies if I'm speaking for something I know very little
>> > about...Wouldn't it be nice if guix home services would accept a user
>> > and a group field?  For the syncthing service, perhaps the user wants to
>> > limit Syncthing's runtime permissions.  So instead of running as the
>> > user, the user would run synthing as a different user with less permissions?
>> 
>> That’s not possible unless the calling user is root, since you’d need
>> the ability to switch users somehow.
>
> On Debian, a user has a list of ‘subordinate user IDs’ which can be switched
> to without root: <https://manpages.debian.org/buster/uidmap/newuidmap.1.en.html>.
>
> Maybe "guix home" could use that mechanism, and this mechanism could be implemented
> on Guix System as well?

Yes but that requires unprivileged user namespaces, which may or may not
be supported—e.g., likely unsupported when using Home on a foreign
distro.

Ludo’.

Re: Code sharing between system and home services

[Vagrant Cascadian]

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

On 2021-10-02, Ludovic Courtès wrote:
> Maxime Devos <maximedevos@telenet.be> skribis:
>> Ludovic Courtès schreef op di 28-09-2021 om 14:21 [+0200]:
>>> Joshua Branson <jbranso@dismail.de> skribis:
>>> 
>>> > Apologies if I'm speaking for something I know very little
>>> > about...Wouldn't it be nice if guix home services would accept a user
>>> > and a group field?  For the syncthing service, perhaps the user wants to
>>> > limit Syncthing's runtime permissions.  So instead of running as the
>>> > user, the user would run synthing as a different user with less permissions?
>>> 
>>> That’s not possible unless the calling user is root, since you’d need
>>> the ability to switch users somehow.
>>
>> On Debian, a user has a list of ‘subordinate user IDs’ which can be switched
>> to without root: <https://manpages.debian.org/buster/uidmap/newuidmap.1.en.html>.
>>
>> Maybe "guix home" could use that mechanism, and this mechanism could be implemented
>> on Guix System as well?
>
> Yes but that requires unprivileged user namespaces, which may or may not
> be supported—e.g., likely unsupported when using Home on a foreign
> distro.

Debian finally enabled it by default in the current stable release,
bullseye, which was released just a few months ago (and it was possible
to enable with a boot flag in earlier releases). Not sure which distros
still disable unprivledged user namespaces...


I am definitely curious to test guix home on a foreign distro at some
point! :)


live well,
  vagrant

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

Re: Code sharing between system and home services

[Ludovic Courtès]

Hi,

Vagrant Cascadian <vagrant@debian.org> skribis:

> Debian finally enabled it by default in the current stable release,
> bullseye, which was released just a few months ago (and it was possible
> to enable with a boot flag in earlier releases).

That’s great news, woohoo!

> Not sure which distros still disable unprivledged user namespaces...

I suppose oldish CentOS & co. as commonly found on HPC clusters…

Ludo’.

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Maxime Devos]

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

Ludovic Courtès schreef op za 02-10-2021 om 16:27 [+0200]:
> Maxime Devos <maximedevos@telenet.be> skribis:
> 
> > Ludovic Courtès schreef op di 28-09-2021 om 14:21 [+0200]:
> > > Hi,
> > > 
> > > Joshua Branson <jbranso@dismail.de> skribis:
> > > 
> > > > Apologies if I'm speaking for something I know very little
> > > > about...Wouldn't it be nice if guix home services would accept a user
> > > > and a group field?  For the syncthing service, perhaps the user wants to
> > > > limit Syncthing's runtime permissions.  So instead of running as the
> > > > user, the user would run synthing as a different user with less permissions?
> > > 
> > > That’s not possible unless the calling user is root, since you’d need
> > > the ability to switch users somehow.
> > 
> > On Debian, a user has a list of ‘subordinate user IDs’ which can be switched
> > to without root: <https://manpages.debian.org/buster/uidmap/newuidmap.1.en.html>;.
> > 
> > Maybe "guix home" could use that mechanism, and this mechanism could be implemented
> > on Guix System as well?
> 
> Yes but that requires unprivileged user namespaces, which may or may not
> be supported—e.g., likely unsupported when using Home on a foreign
> distro.

I don't recall newuidmap requiring unprivileged user namespaces -- it's a setuid binary.
It being unsupported on some foreign distros (*) that aren't Debian doesn't seem
a big problem to me, as long as its use is optional and the limitation is documented.

(*) It's upported on Debian, presumably all Debian derivatives, NixOS
(https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/config/users-groups.nix#L179),
on Guix System according to the output of "type newuidmap" though Guix System
doesn't setup /etc/subuid yet.  That covers a lot of GNU/Linux systems, though certainly not all.

Greetings,
Maxime

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Ludovic Courtès]

Maxime Devos <maximedevos@telenet.be> skribis:

> Ludovic Courtès schreef op za 02-10-2021 om 16:27 [+0200]:
>> Maxime Devos <maximedevos@telenet.be> skribis:
>> 
>> > Ludovic Courtès schreef op di 28-09-2021 om 14:21 [+0200]:
>> > > Hi,
>> > > 
>> > > Joshua Branson <jbranso@dismail.de> skribis:
>> > > 
>> > > > Apologies if I'm speaking for something I know very little
>> > > > about...Wouldn't it be nice if guix home services would accept a user
>> > > > and a group field?  For the syncthing service, perhaps the user wants to
>> > > > limit Syncthing's runtime permissions.  So instead of running as the
>> > > > user, the user would run synthing as a different user with less permissions?
>> > > 
>> > > That’s not possible unless the calling user is root, since you’d need
>> > > the ability to switch users somehow.
>> > 
>> > On Debian, a user has a list of ‘subordinate user IDs’ which can be switched
>> > to without root: <https://manpages.debian.org/buster/uidmap/newuidmap.1.en.html>;.
>> > 
>> > Maybe "guix home" could use that mechanism, and this mechanism could be implemented
>> > on Guix System as well?
>> 
>> Yes but that requires unprivileged user namespaces, which may or may not
>> be supported—e.g., likely unsupported when using Home on a foreign
>> distro.
>
> I don't recall newuidmap requiring unprivileged user namespaces -- it's a setuid binary.

Ah right.  But we’re not call do (system* "/usr/sbin/newuidmap") in
service code, so that’s still a problem, no?

Thanks,
Ludo’.

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Maxime Devos]

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

Ludovic Courtès schreef op ma 04-10-2021 om 16:32 [+0200]:
> Maxime Devos <maximedevos@telenet.be> skribis:
> 
> > Ludovic Courtès schreef op za 02-10-2021 om 16:27 [+0200]:
> > > Maxime Devos <maximedevos@telenet.be> skribis:
> > > 
> > > > Ludovic Courtès schreef op di 28-09-2021 om 14:21 [+0200]:
> > > > > Hi,
> > > > > 
> > > > > Joshua Branson <jbranso@dismail.de> skribis:
> > > > > 
> > > > > > Apologies if I'm speaking for something I know very little
> > > > > > about...Wouldn't it be nice if guix home services would accept a user
> > > > > > and a group field?  For the syncthing service, perhaps the user wants to
> > > > > > limit Syncthing's runtime permissions.  So instead of running as the
> > > > > > user, the user would run synthing as a different user with less permissions?
> > > > > 
> > > > > That’s not possible unless the calling user is root, since you’d need
> > > > > the ability to switch users somehow.
> > > > 
> > > > On Debian, a user has a list of ‘subordinate user IDs’ which can be switched
> > > > to without root: <https://manpages.debian.org/buster/uidmap/newuidmap.1.en.html>;;.
> > > > 
> > > > Maybe "guix home" could use that mechanism, and this mechanism could be implemented
> > > > on Guix System as well?
> > > 
> > > Yes but that requires unprivileged user namespaces, which may or may not
> > > be supported—e.g., likely unsupported when using Home on a foreign
> > > distro.
> > 
> > I don't recall newuidmap requiring unprivileged user namespaces -- it's a setuid binary.
> 
> Ah right.  But we’re not call do (system* "/usr/sbin/newuidmap") in
> service code, so that’s still a problem, no?

It might be possible to modify 'make-forkexec-constructor/container' to call
(exec-command (cons* newuidmap ARGUMENTS-TO-NEWUIDMAP command) ...),
where newuidmap is (search-input-file "newuidmap" '("/run/setuid-programs" "/usr/sbin" "/sbin")).
That path should work on Guix System and many foreign distro, presuming the distro
is configured to make "newuidmap" setuid.

There might be complications w.r.t. bind mounts though (presumably setuid binaries
don't like being called if the (unprivileged) parent process has created some bind mounts?),
so the bind mounting code might need to be performed as a child process of newuidmap,
but in principle, everything should be implemented I think.

I'm not volunteering to write this code though.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Ludovic Courtès]

Hi,

Maxime Devos <maximedevos@telenet.be> skribis:

> It might be possible to modify 'make-forkexec-constructor/container' to call
> (exec-command (cons* newuidmap ARGUMENTS-TO-NEWUIDMAP command) ...),
> where newuidmap is (search-input-file "newuidmap" '("/run/setuid-programs" "/usr/sbin" "/sbin")).
> That path should work on Guix System and many foreign distro, presuming the distro
> is configured to make "newuidmap" setuid.

That looks like opening the door to reproducibility issues.

If we wanted to take that route, it might be slightly more aesthetically
pleasing to rely on a service such as Bubblewrap, but the
non-self-containment issue remains.

Ludo’.

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Maxim Cournoyer]

Hi,

Xinglu Chen <public@yoctocell.xyz> writes:

> On Thu, Sep 23 2021, 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?
>
> The problem is that the configuration records for system and home
> service don’t necessarily have the same fields.  The Syncthing service
> for Guix System has a ‘user’ and a ‘group’ field, which is not really of
> any use in Guix Home, as the only user would be the user invoking ‘guix
> home’.
>
>> 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.
>
> Agreed, that’s what I would like to see as well.
>
>> Would that be feasible?  (Apologies if this has already been
>> discussed!)
>
> Since it might not make sense to have the same records fields for a
> system service and home service, I proposed (in the mail you replied to)
> a ‘define-configuration’ form that would generate a configuration record
> for a system service and optionally one for a home service, without
> having to maintain two records separately.
>
> (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))
>
> It would generate <syncthing-configuration> and
> <home-syncthing-configuration>.  The only difference being that
> <home-syncthing-configuration> doesn’t have a ‘user’ and a ‘group’
> field.

Interesting idea, although I'm a bit wary of adding yet more complexity
to this already relatively complex macro.  I'd favor the cleaner
inheritance idea proposed by Maxime Devos.  I wonder if some fields can
even be masked or removed through inheritance or some other record
transformation (haven't checked).

> It’s probably going to be quite complicated, so it would be good to get
> some feedback/thoughts on it.  Cc Maxim since he has done some work with
> (gnu services configuration).
>
> Also, it’s probably time to properly document (gnu services
> configuration) in the manual.  ;-)

Agreed!

Maxim

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

[Ryan Prior]

On Wednesday, September 15th, 2021 at 8:47 AM, Andrew Tropin
> People will be trying to use home services inside operating systems, and configuration record for system services inside home services.

I think it will be a dismal design failure if we cannot make this just work the way people would expect. Why should we accept that a service which can be run as your user (a "home" service) cannot be run as the system, or vice versa?

Perhaps there are some services that only make sense on the system (for example, I don't suppose a home service defining Linux kernel modules would be appropriate.) So for those corner cases perhaps we must allow marking home-only or system-only services, and make it an error to put one in the other's place. But isn't it the common case that a service declaration can be part of the home or the system, and this merely changes some details in how the thing is run and what fields are required for its configuration?

Ryan

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

[Andrew Tropin]

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

On 2021-09-16 03:05, Ryan Prior wrote:

> On Wednesday, September 15th, 2021 at 8:47 AM, Andrew Tropin
>> People will be trying to use home services inside operating systems, and configuration record for system services inside home services.
>
> I think it will be a dismal design failure if we cannot make this just
> work the way people would expect. Why should we accept that a service
> which can be run as your user (a "home" service) cannot be run as the
> system, or vice versa?
>
> Perhaps there are some services that only make sense on the system
> (for example, I don't suppose a home service defining Linux kernel
> modules would be appropriate.) So for those corner cases perhaps we
> must allow marking home-only or system-only services, and make it an
> error to put one in the other's place. But isn't it the common case
> that a service declaration can be part of the home or the system, and
> this merely changes some details in how the thing is run and what
> fields are required for its configuration?
>
> Ryan

It's not technically possible with current service extension mechanism
to have a service, which can be used in both operating-system and
home-environment.  You can read more on possible improvements to
extension mechanism here:
https://lists.sr.ht/~abcdw/rde-devel/%3C87sg56g97i.fsf%40trop.in%3E

However, currently it's just impossible without a huge (and probably
backward incompatible) refactoring of service extension mechanism and
perhaps all the services.

Even if it would be possible, still don't see too much cases, where the
system service is wanted to be used as home service and vice versa.


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

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

[pinoaffe]

Andrew Tropin writes:
> Even if it would be possible, still don't see too much cases, where the
> system service is wanted to be used as home service and vice versa.

I think that a bunch of the current system services are basically "run
server <x> user <y>" or "run server <x> as its own user", those might
also be useful as home services (if I'm understanding the notion of home
services correctly).

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

[Ludovic Courtès]

Hi,

Andrew Tropin <andrew@trop.in> skribis:

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

Regarding naming, I agree that what you propose would be more
consistent, but we’re not going to rename Guix System modules just now.
:-)

So, from a purely cosmetic standpoint, I’d still prefer (gnu home
services …) rather than (gnu home-services …).  It’s more consistent
with the rest IMO.

Thanks,
Ludo’.

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

[Andrew Tropin]

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

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

> Hi,
>
> Andrew Tropin <andrew@trop.in> skribis:
>
>> 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.
>
> Regarding naming, I agree that what you propose would be more
> consistent, but we’re not going to rename Guix System modules just now.
> :-)
>
> So, from a purely cosmetic standpoint, I’d still prefer (gnu home
> services …) rather than (gnu home-services …).  It’s more consistent
> with the rest IMO.
>
> Thanks,
> Ludo’.

Ok, got the remark, will think on this topic a little more.

For now my personal ranking of the ideas is following:

1. Move to (gnu services ...) :: can(?) provide some additional reusability.
2. Keep as it is right now (gnu home-services ...) :: already works.
3. Move to (gnu home services ...) :: good stylistic change, but breaks
backward compatibility.


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

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

[Ludovic Courtès]

Hi,

(+ Cc: Oleg.)

Andrew Tropin <andrew@trop.in> skribis:

> For now my personal ranking of the ideas is following:
>
> 1. Move to (gnu services ...) :: can(?) provide some additional reusability.
> 2. Keep as it is right now (gnu home-services ...) :: already works.
> 3. Move to (gnu home services ...) :: good stylistic change, but breaks
> backward compatibility.

As I stated in another message, backward compatibility is not a concern
here from the Guix POV (of course it’s a concern for those who were
already using pre-merge Guix Home, but for Guix all these APIs are new.)

(As an aside, part of the reason I asked a few days ago to have more
time for review was precisely so we could refine the APIs before it goes
public.)

I would very much like to have these modules renamed to (gnu home
services …) quickly.  WDYT?  Could the two of you take a look?

Thanks,
Ludo’.

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

[Andrew Tropin]

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

On 2021-09-28 14:26, Ludovic Courtès wrote:

> Hi,
>
> (+ Cc: Oleg.)
>
> Andrew Tropin <andrew@trop.in> skribis:
>
>> For now my personal ranking of the ideas is following:
>>
>> 1. Move to (gnu services ...) :: can(?) provide some additional reusability.
>> 2. Keep as it is right now (gnu home-services ...) :: already works.
>> 3. Move to (gnu home services ...) :: good stylistic change, but breaks
>> backward compatibility.
>
> As I stated in another message, backward compatibility is not a concern
> here from the Guix POV (of course it’s a concern for those who were
> already using pre-merge Guix Home, but for Guix all these APIs are new.)
>
> (As an aside, part of the reason I asked a few days ago to have more
> time for review was precisely so we could refine the APIs before it goes
> public.)
>
> I would very much like to have these modules renamed to (gnu home
> services …) quickly.  WDYT?  Could the two of you take a look?

Doable.

What about moving home services to (gnu services ...)?

It's a little harder, because we probably will need to adjust `guix
system search` and `guix home search`, but other than that seems not too
hard.

However, I'm quite ok with (gnu home services ...), just asking to avoid
one more migration later.

Let me know, which option seems better to you, I can take this task
tomorrow.

>
> Thanks,
> Ludo’.

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

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

[Oleg Pykhalov]

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

Andrew Tropin <andrew@trop.in> writes:

[…]

>> I would very much like to have these modules renamed to (gnu home
>> services …) quickly.  WDYT?  Could the two of you take a look?
>
> Doable.
>
> What about moving home services to (gnu services ...)?
>
> It's a little harder, because we probably will need to adjust `guix
> system search` and `guix home search`, but other than that seems not too
> hard.
>
> However, I'm quite ok with (gnu home services ...), just asking to avoid
> one more migration later.

I'm OK with both variants, but (gnu services) seems more friendly for
sharing the code and as (gnu home services) doesn't look hard to migrate
with current amount of services in (gnu home-services).

> Let me know, which option seems better to you, I can take this task
> tomorrow.

I could try to join the migration on friday, or weekends.  Fill free to
delegate (gnu home-services XYZ) module migration to me here, or IRC.

Oleg.

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

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

[Ludovic Courtès]

Hi!

Oleg Pykhalov <go.wigust@gmail.com> skribis:

> Andrew Tropin <andrew@trop.in> writes:
>
> […]
>
>>> I would very much like to have these modules renamed to (gnu home
>>> services …) quickly.  WDYT?  Could the two of you take a look?
>>
>> Doable.
>>
>> What about moving home services to (gnu services ...)?
>>
>> It's a little harder, because we probably will need to adjust `guix
>> system search` and `guix home search`, but other than that seems not too
>> hard.
>>
>> However, I'm quite ok with (gnu home services ...), just asking to avoid
>> one more migration later.
>
> I'm OK with both variants, but (gnu services) seems more friendly for
> sharing the code and as (gnu home services) doesn't look hard to migrate
> with current amount of services in (gnu home-services).

I’m in favor of (gnu home services) rather than (gnu services), in part
because we have yet to figure out how much can be shared between System
and Home services, and in part because the Home bits are likely useless
for System.

>> Let me know, which option seems better to you, I can take this task
>> tomorrow.
>
> I could try to join the migration on friday, or weekends.  Fill free to
> delegate (gnu home-services XYZ) module migration to me here, or IRC.

Awesome, and I see we already have a new patch series to look at,
thanks!  :-)

Ludo’.

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

[Oleg Pykhalov]

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

Ludovic Courtès <ludo@gnu.org> writes:

[…]

> I’m in favor of (gnu home services) rather than (gnu services), in part
> because we have yet to figure out how much can be shared between System
> and Home services, and in part because the Home bits are likely useless
> for System.

Moved to (gnu home services) in https://issues.guix.gnu.org/50967

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

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

[Xinglu Chen]

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

On Tue, Sep 28 2021, Ludovic Courtès wrote:

> Hi,
>
> (+ Cc: Oleg.)
>
> Andrew Tropin <andrew@trop.in> skribis:
>
>> For now my personal ranking of the ideas is following:
>>
>> 1. Move to (gnu services ...) :: can(?) provide some additional reusability.
>> 2. Keep as it is right now (gnu home-services ...) :: already works.
>> 3. Move to (gnu home services ...) :: good stylistic change, but breaks
>> backward compatibility.
>
> As I stated in another message, backward compatibility is not a concern
> here from the Guix POV (of course it’s a concern for those who were
> already using pre-merge Guix Home, but for Guix all these APIs are new.)
>
> (As an aside, part of the reason I asked a few days ago to have more
> time for review was precisely so we could refine the APIs before it goes
> public.)
>
> I would very much like to have these modules renamed to (gnu home
> services …) quickly.  WDYT?  Could the two of you take a look?

I think it would be better to put home services in the same modules as
system services, i.e., (gnu services mcron) would contain the Mcron
service for Guix System and the Mcron service for Guix Home.  That would
also mean that we wouldn’t have to export ‘job-files’ and
‘shepherd-schedule-action’[1].

I think using (gnu home services …) would only make sense if we already
had (gnu system services …).

WDYT?

[1]: <https://issues.guix.gnu.org/47238>

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

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

[Ludovic Courtès]

Hi,

Xinglu Chen <public@yoctocell.xyz> skribis:

> I think it would be better to put home services in the same modules as
> system services, i.e., (gnu services mcron) would contain the Mcron
> service for Guix System and the Mcron service for Guix Home.  That would
> also mean that we wouldn’t have to export ‘job-files’ and
> ‘shepherd-schedule-action’[1].

Ah true, hmm.  For now it’s okay to export these two things IMO.

Also, more generally, we have to make sure there are no circular
dependencies.  So Home modules can depend on anything else, but System
modules should not depend on Home modules.

> I think using (gnu home services …) would only make sense if we already
> had (gnu system services …).

As I wrote before, I agree in principle, but we’re not going to rename
those modules.  :-)

Thanks,
Ludo’.