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

[Liliana Marie Prikler]

Am Samstag, dem 23.09.2023 um 14:35 +0100 schrieb Bruno Victal:
> 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?
Nope, it was introduced with 3.0.  Again, "I'm not sure" meaning "I
don't know".  Would be nice to have another reviewer check this.  
(Looking at CC:) Maxim? Ludo?

> 
> > (…) 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? …)
Some of these look like bugs, others are a result of trying to cover
too much.  Let's perhaps just cover the simple case of 

[maybe a section]
<var> <op> <val>

where <op> will almost always be "=" rather than worrying about the
specification of e.g. TOML.  If needed, a TOML-specific module can
hopefully reuse the procedures by which we produce INI files.

> > 
> > (…) 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?
Do you have commit access?  The only real place where you can
experiment in the (guix) namespace is on feature branches and if you
feel like you need to experiment further, I'd recommend doing so.  If
not, you could roll out a channel with an extension like the one that
was uses for (guix home)¹.  You might also want to reach out to guix-
devel to try and explain your approach to everyone in terms of how it
would simplify writing services.

Cheers

¹ I think the Guix Home thing itself shows that you can put
technological previews to Guix itself and have them tested (and
depended on!) by many.  This may or may not be what you want, there
sadly isn't a "clean" option.