Re: Why is "append" the activation service's "compose" procedure?

[Chris Marusich <cmmarusich@gmail.com>]

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

ludo@gnu.org (Ludovic Courtès) writes:

> Chris Marusich <cmmarusich@gmail.com> skribis:
>
>> The fold-services procedure always applies the "compose" procedure to a
>> single list.  So why does the activation-service-type use the append
>> procedure as its "compose" procedure?  Wouldn't it more accurately
>> reflect our intent if we used the identity procedure instead?
>
> Yes, you’re right here as well.  :-)
>
> ‘boot-service-type’ has the same problem.
>
> Can you fix both?

I've done this in commit 7874e9e047219cce5ae339e57cd76f158bc19f63.

By the way, I noticed that the cups-service-type also uses "append" as
its "compose" procedure.  I think this is suspicious.  The comment in
the code says:

    ;; Extensions consist of lists of packages (representing CUPS
    ;; drivers, etc) that we just concatenate.
    (compose append)

However, that doesn't seem to be what's going on in the "extend"
procedure that follows it:

    ;; Add extension packages by augmenting the cups-configuration
    ;; 'extensions' field.
    (extend
     (lambda (config extensions)
       (cond
        ((cups-configuration? config)
         (cups-configuration
          (inherit config)
          (extensions
           (append (cups-configuration-extensions config)
                   extensions))))
        (else
         (opaque-cups-configuration
          (inherit config)
          (extensions
           (append (opaque-cups-configuration-extensions config)
                   extensions)))))))

Since there are no examples of extensions of the cups-service-type in
the Guix source tree, I'm not really sure what the intended behavior is.
If the "compute" procedure of any <service-extension> object that
extends the cups-service-type is intended to return a single package,
then my guess is that the "compose" procedure above should really be
identity, not append, in order to more accurately reveal the intent.
However, if the "compute" procedure is intended to return a list of
packages, then my guess is that the cups-service-type may not be
functioning as intended, and to fix it we will need to change the
"compose" procedure to concatenate.

Can someone who is familiar with the cups-service-type clarify what the
"compute" procedure of an extension of the cups-service-type is actually
supposed to return?  I've CC'd Andy, who originally added the
cups-service-type, in the hope that he might respond.

-- 
Chris

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