Services can now have a default value

Services can now have a default value

[Ludovic Courtès]

Hello Guix!

With commit 1bb895eabf74a1e571887eb1521915e668a5c28d, service types can
declare a default value for their instances.  After this one can write:

  (service openssh-service-type)

instead of:

  (service openssh-service-type (openssh-configuration))

A bit of typing saved!

Note that this changes breaks the ABI for services, so make sure to run
“make clean-go && make”.

Feedback welcome!

Ludo’.

Re: Services can now have a default value

[ng0]

Ludovic Courtès transcribed 0.4K bytes:
> Hello Guix!
> 
> With commit 1bb895eabf74a1e571887eb1521915e668a5c28d, service types can
> declare a default value for their instances.  After this one can write:
> 
>   (service openssh-service-type)
> 
> instead of:
> 
>   (service openssh-service-type (openssh-configuration))
> 
> A bit of typing saved!
> 
> Note that this changes breaks the ABI for services, so make sure to run
> “make clean-go && make”.
> 
> Feedback welcome!
> 
> Ludo’.
> 

Before I lock myself out, this is the definition for defaults.
So:
 (service openssh-service-type
          (openssh-configuration
            (port-number 12121)))

becomes:
  (service openssh-service-type
          (port-number 12121))

or is this just a definition for defaults and not the configuration, and
when the configuration is specified it is still like before this commit?
-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Re: Services can now have a default value

[Ricardo Wurmus]

ng0 <contact.ng0@cryptolab.net> writes:

> Before I lock myself out, this is the definition for defaults.
> So:
>  (service openssh-service-type
>           (openssh-configuration
>             (port-number 12121)))
>
> becomes:
>   (service openssh-service-type
>           (port-number 12121))
>
> or is this just a definition for defaults and not the configuration, and
> when the configuration is specified it is still like before this commit?

The “openssh-service-type” has a default value
“(openssh-configuration)”.  If you want to override parts of the default
configuration you can use the “modify-services” syntax.  Your second
snippet is incorrect, because “service” expects a type and a
configuration value, but you gave it a type and “(port-number 12121)”,
which is not a valid configuration.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Services can now have a default value

[ng0]

Ricardo Wurmus transcribed 0.9K bytes:
> 
> ng0 <contact.ng0@cryptolab.net> writes:
> 
> > Before I lock myself out, this is the definition for defaults.
> > So:
> >  (service openssh-service-type
> >           (openssh-configuration
> >             (port-number 12121)))
> >
> > becomes:
> >   (service openssh-service-type
> >           (port-number 12121))
> >
> > or is this just a definition for defaults and not the configuration, and
> > when the configuration is specified it is still like before this commit?
> 
> The “openssh-service-type” has a default value
> “(openssh-configuration)”.  If you want to override parts of the default
> configuration you can use the “modify-services” syntax.  Your second
> snippet is incorrect, because “service” expects a type and a
> configuration value, but you gave it a type and “(port-number 12121)”,
> which is not a valid configuration.
> 
> -- 
> Ricardo
> 
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
> 

Because I still don't think modify-services is documented well enough
and I have only one case where it's working for me, I assume:

As an example,
                   (service openssh-service-type
                            (openssh-configuration
                             (permit-root-login #t)))

Would still work. If it doesn't, I know there is no lint checking for services
in the system config.
-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Re: Services can now have a default value

[Ricardo Wurmus]

ng0 <contact.ng0@cryptolab.net> writes:

> Because I still don't think modify-services is documented well enough

What do you find under-documented about “modify-services”?  The manual
includes an example and a syntax definition, both of which are pretty
clear in my opinion.

Could you please take a look at “6.2.15.3 Service Reference” (especially
where “modify-services” is documented) and “6.2.1 Using the
Configuration System” (sub-heading “System Services”), and tell us what
you consider to be unclear?

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Services can now have a default value

[ng0]

Ricardo Wurmus transcribed 0.6K bytes:
> 
> ng0 <contact.ng0@cryptolab.net> writes:
> 
> > Because I still don't think modify-services is documented well enough
> 
> What do you find under-documented about “modify-services”?  The manual
> includes an example and a syntax definition, both of which are pretty
> clear in my opinion.
> 
> Could you please take a look at “6.2.15.3 Service Reference” (especially
> where “modify-services” is documented) and “6.2.1 Using the
> Configuration System” (sub-heading “System Services”), and tell us what
> you consider to be unclear?
> 
> --
> Ricardo
> 
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
> 

It's probably well documented from a programmers point of view, I have
no open question in that regard, but from a users point of view there
is the question open how many modify-services can there be?
If I want to keep %base-services as is and just want to modify one
of the extra services (openssh for example), how does an example
look like?

Questions like these. You think it's clear because the programming
side is covered. Documentation includes the easy to understand
user (I don't like the separation of btw) side.
-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Re: Services can now have a default value

[Ricardo Wurmus]

ng0 <contact.ng0@cryptolab.net> writes:

> Ricardo Wurmus transcribed 0.6K bytes:
>>
>> ng0 <contact.ng0@cryptolab.net> writes:
>>
>> > Because I still don't think modify-services is documented well enough
>>
>> What do you find under-documented about “modify-services”?  The manual
>> includes an example and a syntax definition, both of which are pretty
>> clear in my opinion.
>>
>> Could you please take a look at “6.2.15.3 Service Reference” (especially
>> where “modify-services” is documented) and “6.2.1 Using the
>> Configuration System” (sub-heading “System Services”), and tell us what
>> you consider to be unclear?
[…]
>
> It's probably well documented from a programmers point of view, I have
> no open question in that regard, but from a users point of view there
> is the question open how many modify-services can there be?

We don’t distinguish between programmers and users.  As the
documentation says, “modify-services” is just syntactic sugar for more
basic list operations.  It takes a list of services and returns another
list of services.  This means you can use it as often as you want and
glue the results together, though it doesn’t really make sense to use it
more often than once when you glue together a custom list of services
and pass that to it.

> If I want to keep %base-services as is and just want to modify one
> of the extra services (openssh for example), how does an example
> look like?

You just need to pass your list of services to “modify-services”.  You
don’t *have* to pass it a pre-defined list of services; *any* list of
services will be fine, even something like

    (cons (tor-service) %default-services)

> Questions like these. You think it's clear because the programming
> side is covered. Documentation includes the easy to understand
> user (I don't like the separation of btw) side.

I don’t see a big difference between these two groups in terms of what
instructions they need.  Users are programming when they write
configurations, and to make that easier we provide more readable syntax
macros like “modify-services”.  The “services” field of the
“operating-system” thing expects you to pass a list of services; it
doesn’t care how you get to that list.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Services can now have a default value

[Ricardo Wurmus]

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

> With commit 1bb895eabf74a1e571887eb1521915e668a5c28d, service types can
> declare a default value for their instances.  After this one can write:
>
>   (service openssh-service-type)
>
> instead of:
>
>   (service openssh-service-type (openssh-configuration))
>
> A bit of typing saved!

Yeah, I like it!  Thanks!

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Services can now have a default value

[Carlo Zancanaro]

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

I have a question related to this, but about a broader issue.

On Sat, Apr 15 2017, Ludovic Courtès wrote:
>   (service openssh-service-type)

Is this supposed to be the preferred way to add a service to your
operating system? Or, put another way, as a service writer: should I
consider a *-service-type to be sufficient to complete the work of
creating a service?

Looking at various services that we have defined at the moment
(according to what is documented), most services have a procedure (ie.
*-service), and maybe also a *-service-type. For example, in "Database
Services" we have postgresql-service and mysql-service, with no
corresponding *-service-type. But then we have redis-service-type
without a *-service to go with it.

I wonder if we would be better off creating *-service procedures for
each *-service-type and documenting them as the canonical way to create
services. That way we could handle things like default arguments through
the usual scheme mechanisms, rather than our own special case.

Carlo

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

Re: Services can now have a default value

[ng0]

Carlo Zancanaro transcribed 1.7K bytes:
> I have a question related to this, but about a broader issue.
> 
> On Sat, Apr 15 2017, Ludovic Courtès wrote:
> >   (service openssh-service-type)
> 
> Is this supposed to be the preferred way to add a service to your
> operating system? Or, put another way, as a service writer: should I
> consider a *-service-type to be sufficient to complete the work of
> creating a service?
> 
> Looking at various services that we have defined at the moment
> (according to what is documented), most services have a procedure (ie.
> *-service), and maybe also a *-service-type. For example, in "Database
> Services" we have postgresql-service and mysql-service, with no
> corresponding *-service-type. But then we have redis-service-type
> without a *-service to go with it.
> 
> I wonder if we would be better off creating *-service procedures for
> each *-service-type and documenting them as the canonical way to create
> services. That way we could handle things like default arguments through
> the usual scheme mechanisms, rather than our own special case.
> 
> Carlo

Yeah I fully agree and sympathize with the need for a canonical
way to create services.
In packages, we habe some kind of framework (with some expectations),
with system-services it is currently as free as it gets in freedom
of expression.
Which is both good and confusing to get started with.

-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Re: Services can now have a default value

[Ludovic Courtès]

Hi!

Carlo Zancanaro <carlo@zancanaro.id.au> skribis:

> I have a question related to this, but about a broader issue.
>
> On Sat, Apr 15 2017, Ludovic Courtès wrote:
>>   (service openssh-service-type)
>
> Is this supposed to be the preferred way to add a service to your
> operating system? Or, put another way, as a service writer: should I
> consider a *-service-type to be sufficient to complete the work of
> creating a service?

Yes.

> Looking at various services that we have defined at the moment
> (according to what is documented), most services have a procedure (ie.
> *-service), and maybe also a *-service-type. For example, in "Database
> Services" we have postgresql-service and mysql-service, with no
> corresponding *-service-type. But then we have redis-service-type
> without a *-service to go with it.
>
> I wonder if we would be better off creating *-service procedures for
> each *-service-type and documenting them as the canonical way to create
> services. That way we could handle things like default arguments through
> the usual scheme mechanisms, rather than our own special case.

It used to be that we would write ‘-service’ procedures.  Then when (gnu
services) was added, each of these procedures would boil down to:

  (define (foo-service #:key (foo foo) (number 42))
    (service foo-service-type
             (foo-configuration (foo foo) (number number))))

There are two issues here:

  1. The default values here are redundant with those we also specify in
     <foo-configuration>.

  2. The ‘-service’ procedures are a bit opaque.  For things like
     ‘modify-services’, we want to expose the fact that we have service
     objects with an associated <foo-configuration> value, rather than
     hide it inside a procedure.

For these reasons, I’ve been progressively suggesting that we avoid
‘-service’ procedures altogether, and deprecate the existing ones.
There are still many of them though, as you write; we should remove
them (patches welcome! easy task for a GuixSD newcomer! :-)).

The default value thing in this thread is about making the ‘service’
form less verbose and closer to what we had with ‘-service’ procedures.

Clearly there’s a parallel between procedures with keyword parameters
and services/configurations records with default field values.  The key
here is that we want first-class objects that we can inspect and derive
from when customizing a system.

Does that clarify things?

Thanks,
Ludo’.

Re: Services can now have a default value

[Ludovic Courtès]

Hi Carlo,

Carlo Zancanaro <carlo@zancanaro.id.au> skribis:

>> There are two issues here:
>>
>>   1. The default values here are redundant with those we also specify in
>>      <foo-configuration>.
>>
>>   2. The ‘-service’ procedures are a bit opaque.  For things like
>>      ‘modify-services’, we want to expose the fact that we have service
>>      objects with an associated <foo-configuration> value, rather than
>>      hide it inside a procedure.
>>
>> For these reasons, I’ve been progressively suggesting that we avoid
>> ‘-service’ procedures altogether, and deprecate the existing ones.
>> There are still many of them though, as you write; we should remove
>> them (patches welcome! easy task for a GuixSD newcomer! :-)).
>
> Could we create a mapping from configuration -> service-type? Or somehow
> embed the service-type inside the configuration record? (I prefer the
> former.) That way we could specify our service list as a list of
> configurations without having to doubly-specify the services.
>
> So then instead of
>
>   (service foo-service-type
>            (foo-configuration (foo #f)
>                               (number 42)))
>
> we could have:
>
>   (foo-configuration (foo #f)
>                      (number 42))
>
> and have the foo-service-type implicitly looked up when instantiating
> the services.

There must be some sort of a mapping between service types and
configuration types, indeed, but I’m not sure how to achieve it.

One solution would be to have all the <foo-configuration> records
inherit (in the OO sense) from <service>, or something along these
lines.

Or we could make <service-type> “struct vtables” and then make
<foo-configuration> instances of those vtables (info "(guile) Vtables").
I’d rather avoid using those interfaces, though (currently the only
record API we use is SRFI-9.)

Or we could have a ‘define-service’ macro that defines both the
<service-type> and the <foo-configuration>, and defines a ‘foo-service’
macro equivalent to (service foo-service-type (foo-configuration …)).

  (define-service-type openssh-service-type
    openssh-service
    (extensions …)
    (configuration
      (port openssh-service-port (default 22))
      (use-pam? openssh-service-use-pam? (default #t))))

and then:

   (operating-system
     ;; …
     (services (cons (openssh-service (port 2222)) %base-services)))

Thoughts?

>> The default value thing in this thread is about making the ‘service’
>> form less verbose and closer to what we had with ‘-service’
>> procedures.
>
> Yeah, okay. I guess I just saw the change and felt like it doesn't
> actually change much. Having a default value saves you a bit of typing,
> but only in the case where you don't want to change any configuration
> for the service.
>
> The other thing that it would buy you (which is more significant) is the
> ability to create services that are required for service extensions, but
> which aren't listed in the operating-system's services. I assume we
> don't want to do that, though, because that could be
> dangerous/surprising.

I’m not sure what you mean.  Is it something like what ‘simple-service’
does?

>> Does that clarify things?
>
> Yes, thanks! Are there discussions somewhere that I can read about how
> this came together? I don't think I've been on the list long enough to
> have seen it myself (or if I have, I can't find them).

It all started with the new service API, which introduced service types
and service objects:

  https://lists.gnu.org/archive/html/guix-devel/2015-09/msg00608.html

The specific issue we’re discussing hasn’t received much attention
though, but it’s been discussed a few times as people were adding new
service definitions.

Thanks,
Ludo’.

Re: Services can now have a default value

[Carlo Zancanaro]

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

Hey Ludo,

On Thu, Apr 20 2017, Ludovic Courtès wrote:
> There must be some sort of a mapping between service types and
> configuration types, indeed, but I’m not sure how to achieve it.
>
> One solution would be to have all the <foo-configuration> records
> inherit (in the OO sense) from <service>, or something along these
> lines.

This was my first thought. I couldn't see how to do OO-style inheritance
with the SRFI-9 API, though. I'm not very experienced with Guile (or
scheme generally), so I might do some more reading about that.

One nice thing about this approach is that now a "service type" is a
scheme record-type, and a "service" is a particular instance of that
record-type, which feels slightly simpler/cleaner to me.

> Or we could make <service-type> “struct vtables” and then make
> <foo-configuration> instances of those vtables (info "(guile) Vtables").
> I’d rather avoid using those interfaces, though (currently the only
> record API we use is SRFI-9.)

I don't know what this means. I had a quick scan of the documentation,
but I'll have to read it in more detail later.

> Or we could have a ‘define-service’ macro that defines both the
> <service-type> and the <foo-configuration>, and defines a ‘foo-service’
> macro equivalent to (service foo-service-type (foo-configuration …)).
>
>   (define-service-type openssh-service-type
>     openssh-service
>     (extensions …)
>     (configuration
>       (port openssh-service-port (default 22))
>       (use-pam? openssh-service-use-pam? (default #t))))
>
> and then:
>
>    (operating-system
>      ;; …
>      (services (cons (openssh-service (port 2222)) %base-services)))

I also thought about this, but I was concerned about things like
dovecot-service, where there are two configuration objects. I wouldn't
want to force us to duplicate code, and create two different service
types, if we wanted services like that in future.

Although, maybe we would actually rather enforce a "one configuration
type per service type" rule, for the sake of modifying services? It's
hard to modify a service if you can't be sure of what the type of the
configuration will be.

Do you have a preference for what approach to use? If we use a macro to
generate things then we retain the same flexibility as the current
approach which removing a bunch of boilerplate, but I'm not sure I have
the best view of the trade-offs involved.

> I’m not sure what you mean.  Is it something like what ‘simple-service’
> does?

I meant something more like what I did with exim-service-type, where I
extend a service just to ensure its presence, then I had to document
you have to have a mail-aliases-service-type in order to use exim. With
a default configuration the mail-aliases-service-type could be
automatically instantiated if it doesn't exist.

I don't think that's a good idea, though.

Carlo

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

Re: Services can now have a default value

[Ludovic Courtès]

Hello,

Carlo Zancanaro <carlo@zancanaro.id.au> skribis:

> On Thu, Apr 20 2017, Ludovic Courtès wrote:
>> There must be some sort of a mapping between service types and
>> configuration types, indeed, but I’m not sure how to achieve it.
>>
>> One solution would be to have all the <foo-configuration> records
>> inherit (in the OO sense) from <service>, or something along these
>> lines.
>
> This was my first thought. I couldn't see how to do OO-style inheritance
> with the SRFI-9 API, though. I'm not very experienced with Guile (or
> scheme generally), so I might do some more reading about that.

SRFI-99 supports inheritance, though there’s currently no SRFI-99 module
in Guile proper:

  https://srfi.schemers.org/srfi-99/srfi-99.html

Oh and there’s also R6RS records, SRFI-35… no shortage of record APIs!
:-)

>> Or we could have a ‘define-service’ macro that defines both the
>> <service-type> and the <foo-configuration>, and defines a ‘foo-service’
>> macro equivalent to (service foo-service-type (foo-configuration …)).
>>
>>   (define-service-type openssh-service-type
>>     openssh-service
>>     (extensions …)
>>     (configuration
>>       (port openssh-service-port (default 22))
>>       (use-pam? openssh-service-use-pam? (default #t))))
>>
>> and then:
>>
>>    (operating-system
>>      ;; …
>>      (services (cons (openssh-service (port 2222)) %base-services)))
>
> I also thought about this, but I was concerned about things like
> dovecot-service, where there are two configuration objects. I wouldn't
> want to force us to duplicate code, and create two different service
> types, if we wanted services like that in future.
>
> Although, maybe we would actually rather enforce a "one configuration
> type per service type" rule, for the sake of modifying services? It's
> hard to modify a service if you can't be sure of what the type of the
> configuration will be.

Right, I would prefer one type per service.  I didn’t know dovecot was
different.

> Do you have a preference for what approach to use? If we use a macro to
> generate things then we retain the same flexibility as the current
> approach which removing a bunch of boilerplate, but I'm not sure I have
> the best view of the trade-offs involved.

A ‘define-service-type’ macro or similar could generate either code the
current framework (with <service-type> and <service> and
<foo-configuration>) or for SRFI-99-style records if we later to go that
route.

So I think we should start by designing this macro.

How does that sound?

>> I’m not sure what you mean.  Is it something like what ‘simple-service’
>> does?
>
> I meant something more like what I did with exim-service-type, where I
> extend a service just to ensure its presence, then I had to document
> you have to have a mail-aliases-service-type in order to use exim. With
> a default configuration the mail-aliases-service-type could be
> automatically instantiated if it doesn't exist.

Oh right.

Well I don’t know, perhaps in some cases it might make sense to
automatically instantiate things depended on.  The advantage is that as
a user of the service (exim for instance) you don’t have to be aware of
the services it expects (improves separation of concern).

So you could blissfully write just:

  (cons (service mediagoblin-service-type)
        %base-services)

and behind the scenes it would add an nginx instance, an mcron instance
with a couple of jobs, a rottlog instance, and so on.

WDYT?

Thanks,
Ludo’.

Re: Services can now have a default value

[Carlo Zancanaro]

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

On Fri, Apr 21 2017, Ludovic Courtès wrote:
> A ‘define-service-type’ macro or similar could generate either code the
> current framework (with <service-type> and <service> and
> <foo-configuration>) or for SRFI-99-style records if we later to go that
> route.
>
> So I think we should start by designing this macro.
>
> How does that sound?

Great! I think that it's sensible to not break things for now, and we
should be able to design the macro to do that.

I'll have a go at it later today and see what I can come up with. (I'm
not very familiar with guile/scheme libraries, but I have played around
a fair bit with macros.)

> Well I don’t know, perhaps in some cases it might make sense to
> automatically instantiate things depended on.  The advantage is that as
> a user of the service (exim for instance) you don’t have to be aware of
> the services it expects (improves separation of concern).
>
> So you could blissfully write just:
>
>   (cons (service mediagoblin-service-type)
>         %base-services)
>
> and behind the scenes it would add an nginx instance, an mcron instance
> with a couple of jobs, a rottlog instance, and so on.
>
> WDYT?

My main concern would be making sure that all of our services have safe
defaults that can be extended. It may lead to surprising outcomes if we
have services spun up which do more than you expect. As an example, if
someone requests exim to start as a dependency, we should make sure it
doesn't turn you into an open relay by default.

Carlo

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

We need an RFC procedure [Re: Services can now have a default value]

[ng0]

Carlo Zancanaro transcribed 2.2K bytes:
> On Fri, Apr 21 2017, Ludovic Courtès wrote:
> > A ‘define-service-type’ macro or similar could generate either code the
> > current framework (with <service-type> and <service> and
> > <foo-configuration>) or for SRFI-99-style records if we later to go that
> > route.
> >
> > So I think we should start by designing this macro.
> >
> > How does that sound?
> 
> Great! I think that it's sensible to not break things for now, and we
> should be able to design the macro to do that.
> 
> I'll have a go at it later today and see what I can come up with. (I'm
> not very familiar with guile/scheme libraries, but I have played around
> a fair bit with macros.)
> 
> > Well I don’t know, perhaps in some cases it might make sense to
> > automatically instantiate things depended on.  The advantage is that as
> > a user of the service (exim for instance) you don’t have to be aware of
> > the services it expects (improves separation of concern).
> >
> > So you could blissfully write just:
> >
> >   (cons (service mediagoblin-service-type)
> >         %base-services)
> >
> > and behind the scenes it would add an nginx instance, an mcron instance
> > with a couple of jobs, a rottlog instance, and so on.
> >
> > WDYT?
> 
> My main concern would be making sure that all of our services have safe
> defaults that can be extended. It may lead to surprising outcomes if we
> have services spun up which do more than you expect. As an example, if
> someone requests exim to start as a dependency, we should make sure it
> doesn't turn you into an open relay by default.
> 
> Carlo

On the matter of 'not breaking things':

I want an formal, publicly tracked (not *just* on the mailinglist) RFC (like in Rust or similar projects) procedure for all things which
can break currently existing configurations. Introducing these changes would
require to document properly what needs to changed so that people can read
about how to fix the mistakes.
Right now to me it seems as if people are mostly talking about such development on IRC or
offlist and then the changes are applied after a QA which sometimes takes a bit of
"don't break stuff" in consideration but is never able to grasp the full effect of
breakage.

The current error output of Guix is not enough if you simply want to do
an update of a system.
If you take a look from the perspective of someone who just wants to
administrate a mailserver, and we break their config by a simple change
of how things are written, the resulting error when you run guix system reconfigure
requires some understanding of Guix and Guile.

And please don't derail this by saying that it's currently beta status. If we are
aiming for general purpose and server adoption, we should look at problems and
solutions from all perspectives.
-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Re: We need an RFC procedure [Re: Services can now have a default value]

[Ricardo Wurmus]

ng0 <contact.ng0@cryptolab.net> writes:

> I want an formal, publicly tracked (not *just* on the mailinglist) RFC (like in Rust or similar projects) procedure for all things which
> can break currently existing configurations. Introducing these changes would
> require to document properly what needs to changed so that people can read
> about how to fix the mistakes.

[…]

API changes are usually explained in the release announcement’s
changelog.  This doesn’t really help between releases, though.  So,
either we release more often (yay!) or we support the old APIs until the
next release (boo!).

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: We need an RFC procedure [Re: Services can now have a default value]

[ng0]

Ricardo Wurmus transcribed 0.7K bytes:
> 
> ng0 <contact.ng0@cryptolab.net> writes:
> 
> > I want an formal, publicly tracked (not *just* on the mailinglist) RFC (like in Rust or similar projects) procedure for all things which
> > can break currently existing configurations. Introducing these changes would
> > require to document properly what needs to changed so that people can read
> > about how to fix the mistakes.
> 
> […]
> 
> API changes are usually explained in the release announcement’s
> changelog.  This doesn’t really help between releases, though.  So,
> either we release more often (yay!) or we support the old APIs until the
> next release (boo!).

Okay, then let me be more specific as you skipped the last part of the
message, which explained my intention.

Let's take this thread, starting at
"https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00329.html".
Ludovic worked on something, pushed it, did some changes to the relevant
documentation but further examples in the documentation which are now
affected weren't fixed with the push. We spent time answering questions
about broken configurations, assuming everyone who uses GuixSD now and
in the future has a fairly competent knowledge of Guile, explaining changes
which could have been avoided - or at least reduced in frequency of questions
asked - by changing examples.
If Ludovic would've presented this change before applying it, it would've
been one of the obvious problems: don't just document the change, change
further documentation sections which rely on this. This way we don't have
a documentation which presents people examples but contradicts itself later
on.
I'm pretty sure I don't have to tell you that casual users would not waste
their time with getting to the solution, and admins want something which in
case of breakage documents the changes before they happen.

Announcing the changes after the discussion about the changes happened is
another thing.
Gentoo sent out "Mails" (local mail) which was then displayed and kept in
the system of the user and it would be visible in the portage (comparable
to "guix package") application.
A bug report on "oh no, my system imploded!" would then ask, have you read
the announcement message?
And archlinux does it in a similar fashion, for both systems changes are
made visible in news on the website.

Even when we would have a "stable" and "unstable" variant, documenting changes
and explaining how to solve problems arising from them should come natural and
in our case it shouldn't involve implied conclusions but rather a good set
of examples.
-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Re: We need an RFC procedure [Re: Services can now have a default value]

[Ludovic Courtès]

Hi ng0,

ng0 <contact.ng0@cryptolab.net> skribis:

> Let's take this thread, starting at
> "https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00329.html".
> Ludovic worked on something, pushed it, did some changes to the relevant
> documentation but further examples in the documentation which are now
> affected weren't fixed with the push. We spent time answering questions
> about broken configurations, assuming everyone who uses GuixSD now and
> in the future has a fairly competent knowledge of Guile, explaining changes
> which could have been avoided - or at least reduced in frequency of questions
> asked - by changing examples.

I think there’s a misunderstanding.  This change is what started the
discussion we’re having with Carlo, but it is a compatible change:
GuixSD configs that previously worked still do.

Thus I don’t think anyone spent time “answering questions about broken
configurations” in this case.  For the same reason, examples in the doc
that were valid before are still valid after the change.

> If Ludovic would've presented this change before applying it, it would've
> been one of the obvious problems: don't just document the change, change
> further documentation sections which rely on this. This way we don't have
> a documentation which presents people examples but contradicts itself later
> on.

What part of the documentation contradicts itself?  I’m confused.

As for posting the change before applying it, I should do more of that.
I’ve taken the bad habit of pushing what I consider as “simple” changes
directly to the repo, but perhaps the criteria should be reconsidered.
:-)

Thoughts?

Ludo’.

Re: We need an RFC procedure [Re: Services can now have a default value]

[Ricardo Wurmus]

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

> As for posting the change before applying it, I should do more of that.
> I’ve taken the bad habit of pushing what I consider as “simple” changes
> directly to the repo, but perhaps the criteria should be reconsidered.
> :-)

I think it’s fine to push simple changes directly.  There hasn’t been a
single instance when you pushed something where I thought that it
shouldn’t have been pushed.

Between releases we are free to change things; they only have to be
mentioned in the ChangeLog for the next release.  ABI breakage can get a
little annoying if one doesn’t know about it and the compilation fails
with unclear errors.

It’s a little unfortunate that packages are developed together with
everything else, because this means that there is no way for people to
opt out of breaking changes until the next release without also opting
out of getting any updates at all.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: We need an RFC procedure [Re: Services can now have a default value]

[ng0]

Ricardo Wurmus transcribed 1.0K bytes:
> 
> Ludovic Courtès <ludo@gnu.org> writes:
> 
> > As for posting the change before applying it, I should do more of that.
> > I’ve taken the bad habit of pushing what I consider as “simple” changes
> > directly to the repo, but perhaps the criteria should be reconsidered.
> > :-)
> 
> I think it’s fine to push simple changes directly.  There hasn’t been a
> single instance when you pushed something where I thought that it
> shouldn’t have been pushed.
> 
> Between releases we are free to change things; they only have to be
> mentioned in the ChangeLog for the next release.  ABI breakage can get a
> little annoying if one doesn’t know about it and the compilation fails
> with unclear errors.
> 
> It’s a little unfortunate that packages are developed together with
> everything else, because this means that there is no way for people to
> opt out of breaking changes until the next release without also opting
> out of getting any updates at all.
> 
> --
> Ricardo
> 
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net

In my opinion it is simple as long as nothing else is affected (or affected
parts are changed at the same time). In other words, if it touches
the way services, packages etc are compossed or definitions which (canonically)
happen to be in the system config, it should be communicated in advance.

I think almost no change Ludovic commited in the time I'm involved broke something,
even if it wasn't simple changes.
To discuss changes doesn't hold them back, it gives others a clear view
on what is happening, on the intentions and maybe to help fix mistakes
in advance.
I don't think anyone produces intenionally bad code, it's just a difference
if you develop in reaction to changes you only know about once they are pushed
(or once feature branches are completed) or if you can discuss about them.
In the first case it's an isolated effort which ressembles a group to the outside,
in the second case it's getting closer to community work.
-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Re: We need an RFC procedure [Re: Services can now have a default value]

[Ludovic Courtès]

Ricardo Wurmus <rekado@elephly.net> skribis:

> It’s a little unfortunate that packages are developed together with
> everything else, because this means that there is no way for people to
> opt out of breaking changes until the next release without also opting
> out of getting any updates at all.

It’s both a strength and a weakness I guess.  The good thing is that we
can make changes that affect everything at once.  The bad thing is what
you mention.

We could use feature branches more, with the downside that they would
probably get little additional testing, precisely because one would have
to choose between features and packages.

Thoughts?

Ludo’.

Re: We need an RFC procedure [Re: Services can now have a default value]

[Petter]

If I may make a suggestion, coming from a place of ignorance.

How about a stable branch that would be opt-in?

On Thu, 27 Apr 2017 15:29:53 +0200
ludo@gnu.org (Ludovic Courtès) wrote:

> Ricardo Wurmus <rekado@elephly.net> skribis:
> 
> > It’s a little unfortunate that packages are developed together with
> > everything else, because this means that there is no way for people to
> > opt out of breaking changes until the next release without also opting
> > out of getting any updates at all.  
> 
> It’s both a strength and a weakness I guess.  The good thing is that we
> can make changes that affect everything at once.  The bad thing is what
> you mention.
> 
> We could use feature branches more, with the downside that they would
> probably get little additional testing, precisely because one would have
> to choose between features and packages.
> 
> Thoughts?
> 
> Ludo’.
> 

Re: We need an RFC procedure [Re: Services can now have a default value]

[Ludovic Courtès]

Petter <petter@mykolab.ch> skribis:

> If I may make a suggestion, coming from a place of ignorance.
>
> How about a stable branch that would be opt-in?

What would be stable in the “stable branch”, packages or Guix?  :-)

A branch where Guix itself is stable would be nice, though it would need
careful merging from master regularly.

A branch where packages are stable (à la Debian stable) would be too
much work (I’m even skeptical it makes any sense given that many
declared and undeclared security vulnerabilities get patched everytime a
piece of software is released…).

Ludo’.

Re: We need an RFC procedure [Re: Services can now have a default value]

[Ricardo Wurmus]

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

> Petter <petter@mykolab.ch> skribis:
>
>> If I may make a suggestion, coming from a place of ignorance.
>>
>> How about a stable branch that would be opt-in?
>
> What would be stable in the “stable branch”, packages or Guix?  :-)
>
> A branch where Guix itself is stable would be nice, though it would need
> careful merging from master regularly.

This would make sense.  It would require some restraint in moving
packages to different modules or breaking some underlying package
features, which would cause ABI breakage.

I do think it would be possible, though.

> A branch where packages are stable (à la Debian stable) would be too
> much work (I’m even skeptical it makes any sense given that many
> declared and undeclared security vulnerabilities get patched everytime a
> piece of software is released…).

Yeah, that wouldn’t make sense.  It’s hard enough to deal with security
issues in current software in a timely fashion.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: We need an RFC procedure [Re: Services can now have a default value]

[Leo Famulari]

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

On Mon, May 22, 2017 at 11:23:23PM +0200, Ricardo Wurmus wrote:
> Ludovic Courtès <ludo@gnu.org> writes:
> > What would be stable in the “stable branch”, packages or Guix?  :-)
> >
> > A branch where Guix itself is stable would be nice, though it would need
> > careful merging from master regularly.
> 
> This would make sense.  It would require some restraint in moving
> packages to different modules or breaking some underlying package
> features, which would cause ABI breakage.
> 
> I do think it would be possible, though.

It's definitely possible, but I'd like to see it proposed in more detail
by the group that will maintain it. It's not okay to start a "stable
branch" unless it will be properly supported.

> 
> > A branch where packages are stable (à la Debian stable) would be too
> > much work (I’m even skeptical it makes any sense given that many
> > declared and undeclared security vulnerabilities get patched everytime a
> > piece of software is released…).
> 
> Yeah, that wouldn’t make sense.  It’s hard enough to deal with security
> issues in current software in a timely fashion.

+1

Anyone who really needs this has a business use case that can support a
private fork, in my opinion.

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

Re: We need an RFC procedure [Re: Services can now have a default value]

[ng0]

Ludovic Courtès transcribed 1.7K bytes:
> Hi ng0,
> 
> ng0 <contact.ng0@cryptolab.net> skribis:
> 
> > Let's take this thread, starting at
> > "https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00329.html".
> > Ludovic worked on something, pushed it, did some changes to the relevant
> > documentation but further examples in the documentation which are now
> > affected weren't fixed with the push. We spent time answering questions
> > about broken configurations, assuming everyone who uses GuixSD now and
> > in the future has a fairly competent knowledge of Guile, explaining changes
> > which could have been avoided - or at least reduced in frequency of questions
> > asked - by changing examples.
> 
> I think there’s a misunderstanding.  This change is what started the
> discussion we’re having with Carlo, but it is a compatible change:
> GuixSD configs that previously worked still do.

Yep, sorry. I figured out that much after having my GuixSD based mailserver
running. Cause and Reaction, okay... but what I've asked about still stands
on its own, it would be better if certain changes are discussed and we come
up with a solid system of announcing changes in case they should break something.
I like how Gentoo and Archlinux solved it.

> Thus I don’t think anyone spent time “answering questions about broken
> configurations” in this case.  For the same reason, examples in the doc
> that were valid before are still valid after the change.
> 
> > If Ludovic would've presented this change before applying it, it would've
> > been one of the obvious problems: don't just document the change, change
> > further documentation sections which rely on this. This way we don't have
> > a documentation which presents people examples but contradicts itself later
> > on.
> 
> What part of the documentation contradicts itself?  I’m confused.

None, the message you initially wrote about the change could've been less
implicit. Like "In addition to $OLD you can now write $NEW, $OLD is still
valid and will work".

> As for posting the change before applying it, I should do more of that.
> I’ve taken the bad habit of pushing what I consider as “simple” changes
> directly to the repo, but perhaps the criteria should be reconsidered.
> :-)
> 
> Thoughts?
> 
> Ludo’.
> 

-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Re: Services can now have a default value

[Carlo Zancanaro]

[-- Attachment #1.1: Type: text/plain, Size: 982 bytes --]


On Fri, Apr 21 2017, Carlo Zancanaro wrote:
> I'll have a go at it later today and see what I can come up with. (I'm
> not very familiar with guile/scheme libraries, but I have played around
> a fair bit with macros.)

Well, it's been a lot longer than "later today", but better late than
never, I guess!

I've attached two patches, one of which is the definition of
define-service-type, and the other which is me changing the
exim-service-type definition to use it.

I made a decision to not try to generate a define-configuration form,
and instead just generate an "old-style" define-record-type for the
configuration. That's mostly just because I don't know how to write
something that works with define-configuration and it felt more
complicated to me. If someone else wants to do that (or help me to
understand it) I'd be supportive.

I'm not really promoting this as something that should be merged at the
moment, but I'm mostly just offering it as food for thought.

Carlo


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-services-Add-define-service-type.patch --]
[-- Type: text/x-diff, Size: 2446 bytes --]

From da085158b30ae983cdaaf172ba2fb97b40d3207d Mon Sep 17 00:00:00 2001
From: Carlo Zancanaro <carlo@zancanaro.id.au>
Date: Sat, 13 May 2017 20:20:27 +1000
Subject: [PATCH 1/2] services: Add `define-service-type`.

* gnu/services.scm (id, define-service-type): New macros.
---
 gnu/services.scm | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/gnu/services.scm b/gnu/services.scm
index 5c314748d..837e75568 100644
--- a/gnu/services.scm
+++ b/gnu/services.scm
@@ -50,6 +50,8 @@
             service-type-extend
             service-type-default-value
 
+            define-service-type
+
             service
             service?
             service-kind
@@ -154,6 +156,37 @@
 
 (set-record-type-printer! <service-type> write-service-type)
 
+(define-syntax-rule (id ctx parts ...)
+  "Assemble PARTS into a raw (unhygienic)  identifier."
+  (datum->syntax ctx (symbol-append (if (symbol? parts)
+                                        parts
+                                        (syntax->datum parts)) ...)))
+
+(define-syntax define-service-type
+  (lambda (stx)
+    (syntax-case stx (extensions configuration)
+      ((define-service-type service-name
+         (extensions exts ...)
+         (configuration (fields tail ...) ...))
+       (with-syntax (((field-accessors ...)
+                      (map (lambda (field)
+                             (id #'stx #'service-name '-configuration- field))
+                           #'(fields ...))))
+         #`(begin
+             (define #,(id #'stx #'service-name '-service-type)
+               (service-type
+                (name 'service-name)
+                (extensions exts ...)))
+             (define-record-type* #,(id #'stx '< #'service-name '-configuration>)
+               #,(id #'stx #'service-name '-configuration)
+               #,(id #'stx 'make- #'service-name '-configuration)
+               #,(id #'stx #'service-name '-configuration?)
+               (fields field-accessors tail ...) ...)
+             (define-syntax-rule (#,(id #'stx #'service-name '-service) config (... ...))
+               (service
+                #,(id #'stx #'service-name '-service-type)
+                (#,(id #'stx #'service-name '-configuration) config (... ...))))))))))
+
 ;; Services of a given type.
 (define-record-type <service>
   (make-service type value)
-- 
2.12.2


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.3: 0002-services-Change-exim-service-type-to-use-define-serv.patch --]
[-- Type: text/x-diff, Size: 2435 bytes --]

From 69c471d4ebe6a24fe11e6488f93616a7afb4467a Mon Sep 17 00:00:00 2001
From: Carlo Zancanaro <carlo@zancanaro.id.au>
Date: Sat, 13 May 2017 20:27:15 +1000
Subject: [PATCH 2/2] services: Change exim-service-type to use
 define-service-type.

* gnu/services/mail.scm: Refactor code to use define-service-type.
---
 gnu/services/mail.scm | 33 +++++++++++++--------------------
 1 file changed, 13 insertions(+), 20 deletions(-)

diff --git a/gnu/services/mail.scm b/gnu/services/mail.scm
index 6305f06f8..ebc7e3d9e 100644
--- a/gnu/services/mail.scm
+++ b/gnu/services/mail.scm
@@ -1693,14 +1693,6 @@ accept from local for any relay
 ;;; Exim.
 ;;;
 
-(define-record-type* <exim-configuration> exim-configuration
-  make-exim-configuration
-  exim-configuration?
-  (package       exim-configuration-package ;<package>
-                 (default exim))
-  (config-file   exim-configuration-config-file ;file-like
-                 (default #f)))
-
 (define %exim-accounts
   (list (user-group
          (name "exim")
@@ -1752,15 +1744,16 @@ exim_group = exim
            (zero? (system* #$(file-append package "/bin/exim")
                            "-bV" "-C" #$(exim-computed-config-file package config-file))))))))
 
-(define exim-profile
-  (compose list exim-configuration-package))
-
-(define exim-service-type
-  (service-type
-   (name 'exim)
-   (extensions
-    (list (service-extension shepherd-root-service-type exim-shepherd-service)
-          (service-extension account-service-type (const %exim-accounts))
-          (service-extension activation-service-type exim-activation)
-          (service-extension profile-service-type exim-profile)
-          (service-extension mail-aliases-service-type (const '()))))))
+(define (exim-profile config)
+  (call-with-values (lambda () (exim-configuration-package config)) list))
+
+(define-service-type exim
+  (extensions (list
+               (service-extension shepherd-root-service-type exim-shepherd-service)
+               (service-extension account-service-type (const %exim-accounts))
+               (service-extension activation-service-type exim-activation)
+               (service-extension profile-service-type exim-profile)
+               (service-extension mail-aliases-service-type (const '()))))
+  (configuration
+   (package       (default exim))
+   (config-file   (default #f))))
-- 
2.12.2


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

Re: Services can now have a default value

[Carlo Zancanaro]

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


On Sat, May 13 2017, Carlo Zancanaro wrote:
> I've attached two patches, one of which is the definition of
> define-service-type, and the other which is me changing the
> exim-service-type definition to use it.

It turns out these patches don't work at all. I wrote the code for them
around a month ago and naively assumed they'd still work. They are quite
broken, so maybe just ignore them. I'm playing around with it again now,
so we'll see what I can come up with.

Carlo

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

Re: Services can now have a default value

[Ludovic Courtès]

Heya,

Carlo Zancanaro <carlo@zancanaro.id.au> skribis:

> On Sat, May 13 2017, Carlo Zancanaro wrote:
>> I've attached two patches, one of which is the definition of
>> define-service-type, and the other which is me changing the
>> exim-service-type definition to use it.
>
> It turns out these patches don't work at all. I wrote the code for them
> around a month ago and naively assumed they'd still work. They are quite
> broken, so maybe just ignore them. I'm playing around with it again now,
> so we'll see what I can come up with.

OK!  Nothing significant changed in the meantime, so perhaps it’s just a
matter of “make clean-go && make”?

BTW, I realized that this won’t be usable directly with services that
use (gnu services configuration).  Maybe that’s OK as a first approach.

Ludo’.

Re: Services can now have a default value

[Christopher Allan Webber]

Ludovic Courtès writes:

> Hello,
>
> Carlo Zancanaro <carlo@zancanaro.id.au> skribis:
>
>> On Thu, Apr 20 2017, Ludovic Courtès wrote:
>>> There must be some sort of a mapping between service types and
>>> configuration types, indeed, but I’m not sure how to achieve it.
>>>
>>> One solution would be to have all the <foo-configuration> records
>>> inherit (in the OO sense) from <service>, or something along these
>>> lines.
>>
>> This was my first thought. I couldn't see how to do OO-style inheritance
>> with the SRFI-9 API, though. I'm not very experienced with Guile (or
>> scheme generally), so I might do some more reading about that.
>
> SRFI-99 supports inheritance, though there’s currently no SRFI-99 module
> in Guile proper:
>
>   https://srfi.schemers.org/srfi-99/srfi-99.html
>
> Oh and there’s also R6RS records, SRFI-35… no shortage of record APIs!
> :-)

A record interface with inheritance!  Neat.

Though hey, if you're going to add inheritance, we also have GOOPS, and
with the clone macro I sent to the mailing list a while ago that I
worked on with Janneke, we even have immutable GOOPS! ;)
Plus then you get generic methods!

 - Chris Webber, who may only be slightly trolling and knows Guix will
   probably never adopt using GOOPS

Re: Services can now have a default value

[Jan Nieuwenhuizen]

Christopher Allan Webber writes:

> A record interface with inheritance!  Neat.

I need to look at that...although ;-P

> Though hey, if you're going to add inheritance, we also have GOOPS, and
> with the clone macro I sent to the mailing list a while ago that I
> worked on with Janneke, we even have immutable GOOPS! ;)
> Plus then you get generic methods!

+1

>  - Chris Webber, who may only be slightly trolling and knows Guix will
>    probably never adopt using GOOPS

:-D

Greetings,
--janneke who'd like to see a lightweight functional GOOPS more
          prominently used

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

Re: Services can now have a default value

[Ludovic Courtès]

Christopher Allan Webber <cwebber@dustycloud.org> skribis:

> Ludovic Courtès writes:
>
>> Hello,
>>
>> Carlo Zancanaro <carlo@zancanaro.id.au> skribis:
>>
>>> On Thu, Apr 20 2017, Ludovic Courtès wrote:
>>>> There must be some sort of a mapping between service types and
>>>> configuration types, indeed, but I’m not sure how to achieve it.
>>>>
>>>> One solution would be to have all the <foo-configuration> records
>>>> inherit (in the OO sense) from <service>, or something along these
>>>> lines.
>>>
>>> This was my first thought. I couldn't see how to do OO-style inheritance
>>> with the SRFI-9 API, though. I'm not very experienced with Guile (or
>>> scheme generally), so I might do some more reading about that.
>>
>> SRFI-99 supports inheritance, though there’s currently no SRFI-99 module
>> in Guile proper:
>>
>>   https://srfi.schemers.org/srfi-99/srfi-99.html
>>
>> Oh and there’s also R6RS records, SRFI-35… no shortage of record APIs!
>> :-)
>
> A record interface with inheritance!  Neat.
>
> Though hey, if you're going to add inheritance, we also have GOOPS, and
> with the clone macro I sent to the mailing list a while ago that I
> worked on with Janneke, we even have immutable GOOPS! ;)
> Plus then you get generic methods!

Point taken!  :-)

I genuinely didn’t even think about GOOPS here ;-), but you’re right.

Ludo’.