[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 17:09 +0900 schrieb 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?
> That error seems to be coming from your sanitizer if I read this
> correctly.

Yes, I think so.  So I do not know what he meant when he said "Other
branches would never be visited."

    Other branches would never be visited because it will fail earlier
    by define-configuration predicate check for extra-config-list?
    (which is basically list?).

I may have misunderstood the location of the code to which his comment
refers.

>> > > > 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.
> You can likewise convert xml->sxml explicitly, there's not really any
> difference here.  Providing this in a sanitizer just makes it more
> user-friendly.

I believe the v5 patch currently does that. Do you think a multi-type
field is acceptable? Or do you think it is better to keep only the
SXML-type field?

Cheers,
-- 
Taiju