guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#60014] [PATCH] activation: make install-special-file match against


From: Josselin Poiret
Subject: [bug#60014] [PATCH] activation: make install-special-file match against pairs as well.
Date: Tue, 13 Dec 2022 11:15:34 +0100

Hi Bruno,

mirai <mirai@makinata.eu> writes:

> The documentation for it says:
> --8<---------------cut here---------------start------------->8---
> The value associated with special-files-service-type services must be a list 
> of tuples where the first element is the “special file” and the second 
> element is its target. 
> --8<---------------cut here---------------end--------------->8---
>
> Which I think is the natural way of doing it. (and communicates the intent, a 
> pair with a path and a file-like object.)

Right, that's unfortunate, although that could be changed to “list of
lists” to make it clearer.

> Of course, (list "path" file-like-obj) works as well but imo the pair is 
> clearer in purpose.
> (what meaning would the third element and so on have, if ever present?)
> This I found out the hard way by getting strange errors until I looked into 
> what happens behind
> `special-files-service-type' and realizing that only lists were accepted.
>
> The mixing of cases is unfortunate (it should have been pairs from the start) 
> but preserves
> compatibility with existing syntax. 

I agree with you here, but then I think to avoid having to maintain both
cases at the same time, all existing uses of special-files-service-type
should also be modified, and only one kind should remain, with the other
triggering some deprecation warning.  You could match to `(path
. file-like)`, and if (list? file-like), throw an exception.

As a sidenote, the main problem is that Guile is not a statically typed
language, but that's a whole other debate to have.

In any case, I don't think this patch will be accepted as-is.  I would
only be partially in favor of the second solution (because it breaks
existing code), while the first solution is low-effort and should work
well enough.  Up to you (and maintainers) to decide.

Best,
-- 
Josselin Poiret





reply via email to

[Prev in Thread] Current Thread [Next in Thread]