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

[Maxime Devos]

Ludovic Courtès schreef op ma 04-10-2021 om 16:32 [+0200]:
> Maxime Devos  skribis:
> 
> > Ludovic Courtès schreef op za 02-10-2021 om 16:27 [+0200]:
> > > Maxime Devos  skribis:
> > > 
> > > > Ludovic Courtès schreef op di 28-09-2021 om 14:21 [+0200]:
> > > > > Hi,
> > > > > 
> > > > > Joshua Branson  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: 
> > > > ;;.
> > > > 
> > > > 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.


signature.asc
Description: This is a digitally signed message part

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

[Ludovic Courtès]

Maxime Devos  skribis:

> Ludovic Courtès schreef op za 02-10-2021 om 16:27 [+0200]:
>> Maxime Devos  skribis:
>> 
>> > Ludovic Courtès schreef op di 28-09-2021 om 14:21 [+0200]:
>> > > Hi,
>> > > 
>> > > Joshua Branson  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: 
>> > ;.
>> > 
>> > 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]

Ludovic Courtès schreef op za 02-10-2021 om 16:27 [+0200]:
> Maxime Devos  skribis:
> 
> > Ludovic Courtès schreef op di 28-09-2021 om 14:21 [+0200]:
> > > Hi,
> > > 
> > > Joshua Branson  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: 
> > ;.
> > 
> > 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


signature.asc
Description: This is a digitally signed message part

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

[Oleg Pykhalov]

Ludovic Courtès  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


signature.asc
Description: PGP signature

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

[Ludovic Courtès]

Maxime Devos  skribis:

> Ludovic Courtès schreef op di 28-09-2021 om 14:21 [+0200]:
>> Hi,
>> 
>> Joshua Branson  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: 
> .
>
> 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: On the naming of System and Home services modules.

[Ludovic Courtès]

Hi,

Xinglu Chen  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’.

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

[Ludovic Courtès]

Hi!

Oleg Pykhalov  skribis:

> Andrew Tropin  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: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Maxime Devos]

Ludovic Courtès schreef op di 28-09-2021 om 14:21 [+0200]:
> Hi,
> 
> Joshua Branson  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: 
.

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

Greetings,
Maxime


signature.asc
Description: This is a digitally signed message part

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

[Oleg Pykhalov]

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


signature.asc
Description: PGP signature

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

[Xinglu Chen]

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

> Hi,
>
> (+ Cc: Oleg.)
>
> Andrew Tropin  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]: 


signature.asc
Description: PGP signature

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

[Andrew Tropin]

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

> Hi,
>
> (+ Cc: Oleg.)
>
> Andrew Tropin  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’.


signature.asc
Description: PGP signature

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

[Ludovic Courtès]

Hi,

(+ Cc: Oleg.)

Andrew Tropin  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: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Ludovic Courtès]

Hi,

Joshua Branson  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.)

[Ludovic Courtès]

Hi,

Xinglu Chen  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: On the naming of System and Home services modules.

[Ludovic Courtès]

Hi Andrew,

Andrew Tropin  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’.

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

[Andrew Tropin]

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

> Hi,
>
> Andrew Tropin  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.



signature.asc
Description: PGP signature

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

[Andrew Tropin]

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  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  and
>> .  The only difference being that
>>  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?)
> and the record types for the home and system configuration
> ( + syncthing-configuration? and 
> 
> + home-syncthing-configuration?).
>
> Using this mechanism, all syncthing-configuration? and 
> home-syncthing-configuration?
> are common-syncthing-configuration?.
>
> Greetings,
> Maxime.

It can work.  Good idea.


signature.asc
Description: PGP signature

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

[Maxim Cournoyer]

Hi,

Xinglu Chen  writes:

> On Thu, Sep 23 2021, Ludovic Courtès wrote:
>
>> Hi,
>>
>> Xinglu Chen  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  and
> .  The only difference being that
>  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: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Maxime Devos]

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.


signature.asc
Description: This is a digitally signed message part

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

[Xinglu Chen]

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  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  and
>> .  The only difference being that
>>  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?)
> and the record types for the home and system configuration
> ( + syncthing-configuration? and 
> 
> + 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?



signature.asc
Description: PGP signature

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

[Joshua Branson]

Xinglu Chen  writes:

> On Thu, Sep 23 2021, Ludovic Courtès wrote:
>
>> Hi,
>>
>> Xinglu Chen  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  and
> .  The only difference being that
>  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.)

[Maxime Devos]

Xinglu Chen schreef op vr 24-09-2021 om 15:35 [+0200]:
> On Thu, Sep 23 2021, Ludovic Courtès wrote:
> 
> > Hi,
> > 
> > Xinglu Chen  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  and
> .  The only difference being that
>  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?)
and the record types for the home and system configuration
( + syncthing-configuration? and 

+ home-syncthing-configuration?).

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

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

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

[Xinglu Chen]

On Thu, Sep 23 2021, Ludovic Courtès wrote:

> Hi,
>
> Xinglu Chen  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  and
.  The only difference being that
 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?



signature.asc
Description: PGP signature

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

[Andrew Tropin]

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

> Hi,
>
> Xinglu Chen  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’.


signature.asc
Description: PGP signature

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

[Ludovic Courtès]

Hi,

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

[Ludovic Courtès]

Hi,

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

[Xinglu Chen]

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@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  record and a
  record.

 There is the problem of  and
  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  would have all the
 fields, but  would have all but the ‘user’
 and ‘group’ fields.

 We could also have a ‘define-home-configuration’ macro that would create
 a  record and optionally, a
  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 ext

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

[Andrew Tropin]

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@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  record and a
>>>  record.
>>>
>>> There is the problem of  and
>>>  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  would have all the
>>> fields, but  would have all but the ‘user’
>>> and ‘group’ fields.
>>>
>>> We could also have a ‘define-home-configuration’ macro that would create
>>> a  record and optionally, a
>>>  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
>>> 

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

[Xinglu Chen]

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@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  record and a
>>  record.
>>
>> There is the problem of  and
>>  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  would have all the
>> fields, but  would have all but the ‘user’
>> and ‘group’ fields.
>>
>> We could also have a ‘define-home-configuration’ macro that would create
>> a  record and optionally, a
>>  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
> o

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

[Andrew Tropin]

On 2021-09-15 09:50, Katherine Cox-Buday wrote:

> Xinglu Chen  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@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.


signature.asc
Description: PGP signature

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

[Andrew Tropin]

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@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  record and a
>  record.
>
> There is the problem of  and
>  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."
>  (h

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

[Andrew Tropin]

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.



signature.asc
Description: PGP signature

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.

[Katherine Cox-Buday]

Xinglu Chen  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@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]

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. 


signature.asc
Description: PGP signature

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

[Xinglu Chen]

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@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  record and a
 record.

There is the problem of  and
 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  would have all the
fields, but  would have all but the ‘user’
and ‘group’ fields.

We could also have a ‘define-home-configuration’ macro that would create
a  record and optionally, a
 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 integra

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

[Maxime Devos]

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.


signature.asc
Description: This is a digitally signed message part

On the naming of System and Home services modules.

[Andrew Tropin]

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