[bug#57963] [PATCH v5 2/2] home: services: Support user's fontconfig configuration.

[Taiju HIGASHI]

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Dienstag, dem 11.10.2022 um 12:54 +0900 schrieb Taiju HIGASHI:
>> We can specify invalid value such as (list "foo" '(foo bar) 123).
> It will be sanitized before that.

I'm sorry, I may not be getting it.

When I reconfigure with the following settings:

--8<---------------cut here---------------start------------->8---
(home-environment
 (packages (list font-google-noto))
 (services
  (append
      (list
       (service home-bash-service-type))
      (modify-services %home-base-services
        (home-fontconfig-service-type
         config => (home-fontconfig-configuration
                    (extra-config
                     (list "<dir>foo</dir>" 123))))))))
--8<---------------cut here---------------end--------------->8---

The following error occurs.

--8<---------------cut here---------------start------------->8---
./pre-inst-env guix home container home-fontconfig-config.scm
Backtrace:
In guix/monads.scm:
    487:9 19 (_ _)
In gnu/services.scm:
  1137:16 18 (_ _)
In guix/monads.scm:
    487:9 17 (_ _)
In gnu/services.scm:
  1140:36 16 (_ _)
In srfi/srfi-1.scm:
   586:17 15 (map1 (#<<service> type: #<service-type home-fontconfig 
7f1926abf…>))
In ice-9/eval.scm:
    155:9 14 (_ #(#(#<directory (gnu home services fontutils) 7f1926df8780>) #))
    159:9 13 (_ #(#(#<directory (gnu home services fontutils) 7f1926df8780>) #))
   173:55 12 (_ #(#(#<directory (gnu home services fontutils) 7f1926df8780>) #))
In gnu/services/configuration.scm:
    124:8 11 (serialize-configuration _ _)
In srfi/srfi-1.scm:
   586:29 10 (map1 (#<<configuration-field> name: font-directories type: str…> 
…))
   586:29  9 (map1 (#<<configuration-field> name: default-font-serif-family …> 
…))
   586:29  8 (map1 (#<<configuration-field> name: default-font-sans-serif-fa…> 
…))
   586:29  7 (map1 (#<<configuration-field> name: default-font-monospace-fam…> 
…))
   586:17  6 (map1 (#<<configuration-field> name: extra-config type: 
maybe-ext…>))
In ice-9/eval.scm:
    155:9  5 (_ #(#(#<directory (gnu home services fontutils) 7f1926df8780>) # 
…))
In srfi/srfi-1.scm:
   586:29  4 (map1 ("<dir>foo</dir>" 123))
   586:17  3 (map1 (123))
In unknown file:
           2 (raise #<&formatted-message format: "'extra-config' type must be 
x…>)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Wrong type (expecting exact integer): #<&formatted-message format: 
"'extra-config' type must be xml string or sxml list, was given: ~a\n" 
arguments: (("<dir>foo</dir>" 123))>
--8<---------------cut here---------------end--------------->8---

Is it sanitized before?

>> > Also, making multi-type fields is debatable, but isn't great IMO.
>>
>> I see. If we had to choose one or the other, I would prefer the
>> string-type field.
> Prefer sexp-type.

I too would like to write my settings in S-expression, but for users who
know the XML format of fontconfig but do not know how to use SXML, I
believe the effort of converting XML to SXML in their head and writing
it cannot be ignored.
Still, users can write settings in SXML and convert them to
strings. That is a choice the user prefers to make; someone who doesn't
know SXML writing strings and converting them to SXML is not a choice
the user prefers to make.

>> > If serialization would support G-exps, we could write
>> >
>> > (list #~"RAW_XML_HERE")
>> >
>> > or even something like this:
>> >
>> > (list #~(READ-THE-WHOLE-FILE #$(local-file "our-old.xml")))
>>
>> Does it mean that the specification does not allow it now? Or does it
>> mean that it is not possible with my implementation?
> I think your serialize would have to unpack the G-Expressions.  You can
> test that with some example configs of your own.

Thank you. I'll give it a try.

Thanks,
-- 
Taiju