[bug#65119] [PATCH 0/8] Sharing service code between Home and System

[Andrew Tropin <andrew@trop.in>]

[-- Attachment #1: Type: text/plain, Size: 2552 bytes --]

On 2023-08-13 13:28, 宋文武 wrote:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> [...]
>>
>> This patch lets us map System services to Home and uses the new
>> mechanism for three services: mcron, dicod, and syncthing.
>>
>>   services: dicod: Remove Shepherd < 0.9.0 compatibility layer.
>>   services: dicod: Pre-build the GCIDE index.
>>   services: syncthing: Use 'match-record'.
>>   services: Define 'for-home'.
>>   home: services: Support mapping of System services to Home services.
>>   home: services: mcron: Define as a mapping of the system service.
>>   home: services: Add dicod.
>>   home: services: Add Syncthing.
>
> I didn't test them, but those changes look good to me!

Hi Ludovic, 宋文武!

Sorry for comming late to the party, I saw this message only a week ago
and didn't have time to make an extensive reply yet, so I will share my
quick thought on the most problematic part and maybe later will
formulate others thoughts in more details.

define-service-type-mapping looks imperative and potentially very
problematic.  Collecting those values in unknown order and applying this
implicit transformation making a good room for foot shooting.  Imagine
someone would like to use his own (let's say) shepherd home service
implementation and will add this to one of the source files of their
channel:

--8<---------------cut here---------------start------------->8---
(define-service-type-mapping
  shepherd-root-service-type => my-home-shepherd-service-type)
--8<---------------cut here---------------end--------------->8---

What happens if somebody will use his channel just for getting some
package?  Very likely it would break the build or in the worst case it
will build with unexpected service implementation under the hood.

I had [1][2] and still have concerns about macros and records
composability and reusability.  I personally don't like excessive usage
of them in general.  By adding more macros, already quite complex guix
services mechanism becomes even more harder to learn, inspect, reason
about and work with.  In addition to that it has a major technical issue
mentioned above.  I'm strongly against this change and would suggest to
revert it.

I hope it doesn't sound rude and I'm really thankful for your work on
this, but I just think it's not the right solution, at least yet, in its
current form.

[1]: https://yhetil.org/guix-devel/878rvp1deg.fsf@trop.in/T/#u
[2]: https://yhetil.org/87ild88kax.fsf@trop.in
-- 
Best regards,
Andrew Tropin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]