[bug#63985] [PATCH v3 00/11] Service subsystem improvements

[Bruno Victal <mirai@makinata.eu>]

On 2023-09-16 22:55, Liliana Marie Prikler wrote:
> I'm not sure whether serializer options really add much value.  You can
> use functional programming to define serializers for you and pass those
> options in a cleaner way IMHO.  The documentation should be updated as
> the changes are made.  As for the switch to SRFI 171, I'm not sure
> whether backwards compatibility with Guile 2.2 is a requirement
> somewhere; if it isn't, that change is probably fine.

Is SRFI-171 not available in Guile 2.2?
Your last remark surprised me though: is Guix not running with Guile 3.0?
I was the impression that this was the case since otherwise wouldn't this
imply that `spawn' & co. can't be used anywhere?

> Even if Guile implemented SRFI 233 now, I'm not sure we could use it
> tomorrow.  And even once we can use SRFI 233, we can keep backwards-
> compatibility be re-exporting things. (…)

In that aspect I'm willing to be patient vs. maintaining a temporary
(read as: permanent) code though I think that it should be possible to
make it backwards-compatible, even if we completely gut out its innards
later and replace them with SRFI-233.

> (…) The question is how necessary it
> will be for us to maintain our own INI format writer.  NetworkManager
> is one use case, but perhaps we have others (perhaps even in the gnome
> world – gdm maybe?)

Certainly there are many applications that make use of INI-like files
for configuration and for INI ones it would be convenient, though I
should caution that there are many things that can look like INI but
aren't:

* NetworkManager accepts some entries that have append behavior via
'KW += val' and have repetition. In some cases I think the ordering
matters too. (Since our define-configuration definition for it
doesn't attempt to fully cover every nook and cranny of it I think
using INI here doesn't hurt.)

* TOML

* Files that can have leading entries but without a section. These
can be thought to belong to some top level but invisible section yet
the generic-ini doesn't handle these. (yet)


There's some assumptions I made while writing generic-ini which make
it not as generic as imparted by its name and as such, it can only be
used in the following conditions:

* The ordering of the entries and sections doesn't matter.
* Every entry belongs to a section.
* (… perhaps more? …)

>> Naturally these are no longer relevant if this generic-ini module
>> approach is abandoned.
> I think we can still upgrade this to define-configuration without a
> generic-ini, but see above.  That being said, we can certainly split> this into two series (…)

Sure.

> (…) at the point you currently feel comfortable with
> and work from there.
> 
> WDYT?

I'm inclined to write-off the generic-ini though as discussed above,
there's some demand for some kind of INI format writer so personally
I'd be OK with temporarily maintaining this writer if we can really
make it an experiment/true to the word “temporary” thing. This would
mean that:

* It should be only used internally by services living in Guix
repository. I'm OK with going around and reworking/replacing usages
of it when the time comes to retire it/when guile gets this INI thing
natively. (i.e. #:export (…) doesn't mean that I'm intending it to
be used outside of the repo with stability promises.)


WDYT?

-- 
Furthermore, I consider that nonfree software must be eradicated.

Cheers,
Bruno.