[bug#75063] [PATCH 1/2] gnu: dict: Add symbols to help users configure FreeDict with dicod.

[Runciter]

Hello,

I'll squash both commits, simplify the configuration if appropriate,
update symbol names and improve the documentation in the beginning of
next week.

Meanwhile I have not tested much yet but by reviewing code I found
something which is possibly interesting.


>> +(define %dictorg-handler
>> +  (dicod-handler (name "dictorg")
>> +                 (module "dictorg")
>> +                 (options (list #~(string-append "dbdir=/")))))
>
> I believe we don’t even need that; it’s built-in.

You found something simpler but I'll need to dive into the dicod.conf
file in the store. See below.

And sorry for the call to string-append with just one argument, I also
seem to have included a useless G-exp... Probably a leftover from a
previous version of mine.

>> +(define (freedict-dictorg-database dict-name)
>> +  "Return a record of type @code{<dicod-database>} that configures a
>> +database for the freedict multilingual dictionary named by the string
>> +DICT-NAME."
>> +  (dicod-database (name (string-append "freedict-"
>> +                                       dict-name))
>> +                  (complex? #t)
>
> What does ‘complex?’ do actually?  (Seems to work without it.)

Reviewing the code in the (gnu services dict) module, the relevant
symbol is `database->text` defined inside the `dicod-configuration-file`
procedure.

`database->text` recurses into itself one time maximally, so that dicod
gets one auto-generated handler with default handler options from the
service module for each configured database which has `complex?`
evaluating to #f, independently (TBC) from what the system
configuration's explicit handlers and other non-complex databases are
configuring.

dicod has modules, handlers referencing a module, and databases
referencing a handler. The latter two are user-configurable. dicod has
hard-coded modules and I suppose it has no hard-coded handlers. In any
case, as far as the Guix service module design goes, dicod is always
supposed to get all of its handlers from Guix, either flexible handlers
from the system configuration, or default handlers from the service
module.

This being the inferred design intent, 3 things are possibly not ideal
in the way Guix handles dicod, by increasing order of importance:

1. In the Guix manual, the documentation of the `complex?` field may be
   slightly misleading. Strictly speaking it's the handler configuration
   which is complex when `complex?` is true, not the database
   configuration. Within dicod, those 2 levels of configuration are at
   least partially substitutable to each other, but they're not
   occupying the same position along an inheritance chain.

2. Here's one thing that I must experiment with before finishing this
   patch: some interactions between the service module and the system
   configuration might result in a "dirty" dicod configuration file
   defining the same handler multiple times. There are 2 cases which can
   result in this situation, and I don't think this is caught by the
   service module (TBC):
       a. same handler name defined explicitly by the system configuration,
          and by the service module when the system configuration also
          defines a non-complex database naming the same handler;
       b. System configuration containing multiple non-complex databases
          naming the same handler. If I have to bet right now, this is
          what happens with the simple system configuration you found.
          There's reason to think the dicod configuration file is "dirty"
          but non-failing, and in any case non-risky at run-time in this
          case, because the multiply-defined handler(s) should be all
          configured exactly to an identical default.

3. Are we possibly configuring dicod to load some of its modules
   multiple times, or possibly misleading users into doing it? This
   could be also non-failing but a most undesirable thing to do.

Regards,
Runciter