~abcdw/rde-devel

7 3

Naming conventions

Details
Message ID
<87y2cqifpx.fsf@yoctocell.xyz>
DKIM signature
pass
Download raw message
Since Guix Home is still in early phases of development, I thought it
would be a good idea to bring up the problem of naming things before we
have too many services.

This is what the situation looks like right now:

* Service types are prefixed with with ‘home-’,
  e.g. ‘home-zsh-service-type’.

* Configuration record types are also prefixed with ‘home-’,
  e.g. ‘home-emacs-configuration’.

* Extensions for other services don’t really have a consistent naming
  scheme, some are prefixed with ‘add-’, e.g. ‘add-emacs-packages’,
  while others are prefixed with ‘home-’ and end with the name of the
  target service, e.g. ‘home-gnupg-activation-service’ provides
  extension for ‘home-activation-service-type’.

One question is: When should we prefix things with ‘home-’?

Some of the private procedures are prefixed with ‘home-’, this seems a
little unnecessary since they won’t be used on other modules, and users
certainly won’t try to use them, unless they really know what they are
doing.

The configuration record types, e.g. ‘home-gnupg-configuration’ don’t
necessarily have to be prefixed with ‘home-’.  One of the things we
would like to avoid is code duplication with Guix proper,  if Guix
proper already has a ‘mcron-configuration’ record type, we would like to
be able to just reuse it instead of creating our own
‘home-mcron-configuration’ record type.  It is the service type that
actually controls how a record type is going to end up in the user’s
home environment/operating system.  I think it makes sense to drop the
‘home-’ prefix from the configuration record types.

Guix System already has a service for Getmail (gnu services getmail),
this could just as well be used in Guix Home, and we could just add a
‘home-getmail-service-type’ and some helper functions to make it put the
configuration in the correct place instead of having to re-write a
‘home-getmail-configuration’ record type

Another thing I have noticed is that the names for the Shepherd services
also start with ‘home-’, e.g. ‘home-mcron’.  This seems unnecessary
since running ‘herd status’ will only display the services for the
current user, system services will only be displayed if ‘herd status’ is
run as root.

As a side-note: When merging with Guix proper, should we create a new
(gnu home-services) namespace or should we just put the services in the
(gnu services) namespace?  With the latter, we could for example just
add ‘home-mcron-service-type’ to (gnu services mcron) and modify
‘mcron-shepherd-services’ to use a different G-expression to start the
mcron daemon depending on if it is a system service or a user service.

Have a good weekend!
Details
Message ID
<87lf8p8x82.fsf@trop.in>
In-Reply-To
<87y2cqifpx.fsf@yoctocell.xyz> (view parent)
DKIM signature
missing
Download raw message
Thank you, you too!)
Details
Message ID
<878s4l8kai.fsf@trop.in>
In-Reply-To
<87lf8p8x82.fsf@trop.in> (view parent)
DKIM signature
missing
Download raw message
> Since Guix Home is still in early phases of development, I thought it
> would be a good idea to bring up the problem of naming things before we
> have too many services.

> This is what the situation looks like right now:

> * Service types are prefixed with with ‘home-’,
>   e.g. ‘home-zsh-service-type’.

> * Configuration record types are also prefixed with ‘home-’,
>   e.g. ‘home-emacs-configuration’.

> * Extensions for other services don’t really have a consistent naming
>   scheme, some are prefixed with ‘add-’, e.g. ‘add-emacs-packages’,
>   while others are prefixed with ‘home-’ and end with the name of the
>   target service, e.g. ‘home-gnupg-activation-service’ provides
>   extension for ‘home-activation-service-type’.

> One question is: When should we prefix things with ‘home-’?

Very good question.

> Some of the private procedures are prefixed with ‘home-’, this seems a
> little unnecessary since they won’t be used on other modules, and users
> certainly won’t try to use them, unless they really know what they are
> doing.

Yep, I agree, most of procedures doesn't require prefix and it make
sense not to use it in many cases.  Not sure if we need a strict naming
rules here.  Personally I do not like Guix' approach of naming a
function with extension target, for me it's better to describe what
function returns rather than what it extends.

> The configuration record types, e.g. ‘home-gnupg-configuration’ don’t
> necessarily have to be prefixed with ‘home-’.  One of the things we
> would like to avoid is code duplication with Guix proper,  if Guix
> proper already has a ‘mcron-configuration’ record type, we would like to
> be able to just reuse it instead of creating our own
> ‘home-mcron-configuration’ record type.  It is the service type that
> actually controls how a record type is going to end up in the user’s
> home environment/operating system.  I think it makes sense to drop the
> ‘home-’ prefix from the configuration record types.

I had this question near first days of Guix Home.  It's tempting to
reuse already existing configuration record, but we won't do it:

Sometimes we want to reuse it (shepherd-configuration), sometimes the
service has very different purpose (or maybe same purpose, but slightly
different fields, like additional xdg-flavor? flag) and we don't want to
reuse, but want to create a new record type for that.  It means that at
in some cases we will have home-A-configuration and A-configuration, in
some cases only A-configuration and it will be very confusing for users,
which configuration to use.  That's why I think we have to prefix all
home configurations with home-, not sure about nested records, but
they probably have to have prefix too.

One of the reasons why I do not like macros is that we can't just:
(define home-mcron-configuration mcron-configuration)

> Guix System already has a service for Getmail (gnu services getmail),
> this could just as well be used in Guix Home, and we could just add a
> ‘home-getmail-service-type’ and some helper functions to make it put the
> configuration in the correct place instead of having to re-write a
> ‘home-getmail-configuration’ record type

Sadly, we won't be able to reuse as much code as you think.  We have to
change directory default value, which leads to creating a separate
home-getmail-configuration.  Not sure that there is much sense to try to
reuse nested records, maybe it is.  Functions of course can and should
be reused in many cases if they not rely on record type.  Macros really
complicates composition.

> Another thing I have noticed is that the names for the Shepherd services
> also start with ‘home-’, e.g. ‘home-mcron’.  This seems unnecessary
> since running ‘herd status’ will only display the services for the
> current user, system services will only be displayed if ‘herd status’ is
> run as root.

Probably home-mcron is the only one with the prefix, yep, I also think
shepherd services do not need it.

> As a side-note: When merging with Guix proper, should we create a new
> (gnu home-services) namespace or should we just put the services in the
> (gnu services) namespace?  With the latter, we could for example just
> add ‘home-mcron-service-type’ to (gnu services mcron) and modify
> ‘mcron-shepherd-services’ to use a different G-expression to start the
> mcron daemon depending on if it is a system service or a user service.

I don't think we should mix home-services with services.  It will
complicate things for both developers and users, especially for users.

In previous threads by escaping duplications I meant that we will be
trying to keep only one version of service in most cases (system-service
or home-service), if it's not possible maybe we will be able to share
part of implementation between them, but this is secondary.

We can completely prevent duplication like that:
https://search.nixos.org/options?channel=20.09&show=programs.chromium.enable&from=0&size=50&sort=relevance&query=chromium
https://rycee.gitlab.io/home-manager/options.html#opt-programs.chromium.enable

Good question, Xinglu and great arguments!)  Made me rethink and clarify to
myself some things.  Thank you)
Details
Message ID
<8735utgufh.fsf@yoctocell.xyz>
In-Reply-To
<878s4l8kai.fsf@trop.in> (view parent)
DKIM signature
pass
Download raw message
On Tue, May 11 2021, Andrew Tropin wrote:

>> The configuration record types, e.g. ‘home-gnupg-configuration’ don’t
>> necessarily have to be prefixed with ‘home-’.  One of the things we
>> would like to avoid is code duplication with Guix proper,  if Guix
>> proper already has a ‘mcron-configuration’ record type, we would like to
>> be able to just reuse it instead of creating our own
>> ‘home-mcron-configuration’ record type.  It is the service type that
>> actually controls how a record type is going to end up in the user’s
>> home environment/operating system.  I think it makes sense to drop the
>> ‘home-’ prefix from the configuration record types.
>
> I had this question near first days of Guix Home.  It's tempting to
> reuse already existing configuration record, but we won't do it:
>
> Sometimes we want to reuse it (shepherd-configuration), sometimes the
> service has very different purpose (or maybe same purpose, but slightly
> different fields, like additional xdg-flavor? flag) and we don't want to
> reuse, but want to create a new record type for that.  It means that at
> in some cases we will have home-A-configuration and A-configuration, in
> some cases only A-configuration and it will be very confusing for users,
> which configuration to use.

Good point.

> That's why I think we have to prefix all home configurations with
> home-, not sure about nested records, but they probably have to have
> prefix too.

Hmm, that seems to be the best way to keep things consistent.

>> Guix System already has a service for Getmail (gnu services getmail),
>> this could just as well be used in Guix Home, and we could just add a
>> ‘home-getmail-service-type’ and some helper functions to make it put the
>> configuration in the correct place instead of having to re-write a
>> ‘home-getmail-configuration’ record type
>
> Sadly, we won't be able to reuse as much code as you think.  We have to
> change directory default value, which leads to creating a separate
> home-getmail-configuration.

Oh, yeah, I didn’t think about the default value for a field.

> Not sure that there is much sense to try to reuse nested records,
> maybe it is.

It could be nice, but won’t be possible if we also prefix them with
‘home-’, as you mentioned above.

>> As a side-note: When merging with Guix proper, should we create a new
>> (gnu home-services) namespace or should we just put the services in the
>> (gnu services) namespace?  With the latter, we could for example just
>> add ‘home-mcron-service-type’ to (gnu services mcron) and modify
>> ‘mcron-shepherd-services’ to use a different G-expression to start the
>> mcron daemon depending on if it is a system service or a user service.
>
> I don't think we should mix home-services with services.  It will
> complicate things for both developers and users, especially for users.

Would it tough?  If all the home services are prefixed with ‘home-’ it
would be pretty clear if a configuration was meant for Guix System or
Guix Home, wouldn’t it?

> In previous threads by escaping duplications I meant that we will be
> trying to keep only one version of service in most cases (system-service
> or home-service), if it's not possible maybe we will be able to share
> part of implementation between them, but this is secondary.

Yeah, it would be nice to be able to share at least parts of the
implementation of the system mcron service and the home mcron service.

> We can completely prevent duplication like that:
> https://search.nixos.org/options?channel=20.09&show=programs.chromium.enable&from=0&size=50&sort=relevance&query=chromium
> https://rycee.gitlab.io/home-manager/options.html#opt-programs.chromium.enable

Yeah, I don’t see why anyone would configure Chromium system-wide
instead of per-user.

> Good question, Xinglu and great arguments!)  Made me rethink and clarify to
> myself some things.  Thank you)

You are welcome!  I think it was a good idea to write down my own
thoughts to get a better picture of everything.
Details
Message ID
<CABrWRW1XYwv1z+QJvc0zGaRa+Dy0dKQj0d+3-KbRpQR=WrY4pA@mail.gmail.com>
In-Reply-To
<8735utgufh.fsf@yoctocell.xyz> (view parent)
DKIM signature
missing
Download raw message
> Would it be tough?  If all the home services are prefixed with 'home-' it
> would be pretty clear if a configuration was meant for Guix System or
> Guix Home, wouldn't it?

Technically doesn't have to be so, but semantically it would be a mess.
Home's version control services is a way to configure user's git/hg
tools, while system's version control services are web interfaces for
exposing git repos via HTTP or other protocols.

Maybe it's not a big deal, but I think it's better to keep them
separate.  Can discuss it again later with Guix devs.
Details
Message ID
<871ra5hz4g.fsf@yoctocell.xyz>
In-Reply-To
<CABrWRW1XYwv1z+QJvc0zGaRa+Dy0dKQj0d+3-KbRpQR=WrY4pA@mail.gmail.com> (view parent)
DKIM signature
pass
Download raw message
On Mon, May 17 2021, Andrew Tropin wrote:

>> Would it be tough?  If all the home services are prefixed with 'home-' it
>> would be pretty clear if a configuration was meant for Guix System or
>> Guix Home, wouldn't it?
>
> Technically doesn't have to be so, but semantically it would be a mess.
> Home's version control services is a way to configure user's git/hg
> tools, while system's version control services are web interfaces for
> exposing git repos via HTTP or other protocols.
>
> Maybe it's not a big deal, but I think it's better to keep them
> separate.  Can discuss it again later with Guix devs.

Yeah, it would be a good idea to see what the Guix maintainers think.
Maxime Devos
Details
Message ID
<6d32cb5547ca792ebf57febde1577f372c528540.camel@telenet.be>
In-Reply-To
<878s4l8kai.fsf@trop.in> (view parent)
DKIM signature
pass
Download raw message
Andrew Tropin schreef op di 11-05-2021 om 16:36 [+0300]:
> [...]
> 
> One of the reasons why I do not like macros is that we can't just:
> (define home-mcron-configuration mcron-configuration)

Use define-syntax and identifier-syntax instead, then it will work.
Example for the 'package' macro:

(use-modules (guix packages) (gnu packages base))
(define-syntax my-package (identifier-syntax package))
(define my-hello
  (my-package
    (inherit hello)
    (name "my-hello")))
my-hello ; $1 = #<package my-hello@2.10 7fd2455b9b40>

Greetings,
Maxime.
Details
Message ID
<87tuimhsrm.fsf@trop.in>
In-Reply-To
<6d32cb5547ca792ebf57febde1577f372c528540.camel@telenet.be> (view parent)
DKIM signature
missing
Download raw message
On 2021-09-15 12:20, Maxime Devos wrote:

> Andrew Tropin schreef op di 11-05-2021 om 16:36 [+0300]:
>> [...]
>> 
>> One of the reasons why I do not like macros is that we can't just:
>> (define home-mcron-configuration mcron-configuration)
>
> Use define-syntax and identifier-syntax instead, then it will work.
> Example for the 'package' macro:
>
> (use-modules (guix packages) (gnu packages base))
> (define-syntax my-package (identifier-syntax package))
> (define my-hello
>   (my-package
>     (inherit hello)
>     (name "my-hello")))
> my-hello ; $1 = #<package my-hello@2.10 7fd2455b9b40>
>
> Greetings,
> Maxime.

Nice trick, thank you!)

Probably will need to alias getters manually or use the one provided by
original record, but still glad to know that it's possible, thank you
again.
Reply to thread Export thread (mbox)