On 2023-09-09 00:18, Ludovic Courtès wrote: > Hi Andrew, > > Andrew Tropin skribis: > >> Yes, and and this is exactly what this solution does and in addition to >> that it hides it under the sweet define-service-type-mapping interface. >> `set!` explicitly communicates the danger of usage, >> define-service-type-mapping does not. >> >> >> 1. We introduce a global state here and infect potentially all the >> modules from all channels with it + mask it with nice interface. => Now >> the result of evaluation depends on the order source files are read. >> Every channel can break valid user's configurations with perfectly legal >> public guix API. We make reloading of the modules and REPL-driven >> development in general a huge pain in the lower back. >> >> >> 2. The service extension mechanism is already quite complex to understand >> on its own, in addition to that the devirsity of record creation macros >> / DSLs (define-record-type, define-record-type*, define-configuration) >> doesn't make the situation better. We introduce one more DSL on top of >> couple existing. => Learning curve raises even higher. Inspecting, >> navigating and debugging such code becomes harder. It prevents future >> extension with for-container or for-development-environment. It saves >> couple of lines and avoids some minor repetions at the moment, but not >> sure that it's the right way to reuse the stuff between home and system >> services. > > I understand what you’re saying. I don’t necessarily agree with all of > it because I believe abstraction is a fundamental part of programming; > abstractions can sometimes be wrong or misleading of course, and that’s > what we should strive to avoid. > > Back to this patch series, we’ve had one concrete illustration of a > shortcoming: > > https://issues.guix.gnu.org/65510 > > I’m aware of this and agree it needs to be addressed. > > In assessing this patch series, one should keep in mind that it solves a > longstanding issue with Guix Home (code duplication and the inability to > share service code with Guix System), one for which no other solution > was proposed AFAIK. 1. One of the possible options is to use free-style configurations for services, so we can reuse a lot of code and drastically decrease duplication (only the service definition itself and a one configuration record) and maintanance burden. https://yhetil.org/guix/87ild88kax.fsf@trop.in/ We have only two maintainers and have more than the half of a hundred services in rde, which is not that far from guix itself (258 services). 2. Another option is to rethink service extension mechanism a little bit and maybe make it more polymorphic. https://lists.sr.ht/~abcdw/rde-devel/%3C87sg56g97i.fsf%40trop.in%3E (Just making a rough example of naive implementation) Instead of referencing service by it's value, we could reference its name. This way we can write one service for Home and System, which always extends 'system-accounts-service-type, and for home case provide a different implementation for it, so when we build operating system system-accounts-service-type will add users to /etc/passwd, when we build home-environment system-accounts-service-type will do nothing. Adjusting the logic of the extension based on presence/absence of a particular service can be very useful to make it possible to reuse configuration for Home and System services directly. However, improving service extension mechanism in such way, keeping backward compatibility and upstreaming it is a hard and very time-consuming task. So in rde we just implemented a feature mechanism on top of service extension mechanism to solve challenges mentioned above and it works great. It would be even greater if we could just do the same with plain services. My point here is: let's solve this issue on another level of abstraction, by improving service extension mechanism, not by creating a new level of abstraction (as we did in rde or in this patch series) to cover the wholes in the previous level. I would be glad to cooperate on this and design possible improvements. > My own assessment, having reviewed patches adding Home services (in all > loneliness I must say) is that the outcome is positive, in spite of the > shortcoming mentioned above. > in all loneliness I must say In some previous threads on guix-devel/guix-patches I mentioned, that we will maintain home services for rde separately https://git.sr.ht/~abcdw/rde/tree/master/item/doc/decision-log/0004-rde-flavor-guix-services.org and thus all (most of) the home services coming to guix-patches won't be used by rde or me personally. Despite the fact that I would be glad to help with reviews, I already work hard (almost fulltime) on guix, guile and emacs ecosystem in parrallel to running from the war and probably reviewing home services on guix-patches is less valuable use of my time both for me and for the community. > In assessing this patch series, one should keep in mind that it solves a > longstanding issue with Guix Home (code duplication and the inability to > share service code with Guix System), one for which no other solution > was proposed AFAIK. I think that your concern about code duplication is valid (and I'm aware of the issue probably even longer :) ) and I would be glad to cooperate to solve it. However, I'm almost sure that it should be done on service extension mechanism level. If this make sense, we can discuss possible solutions in more details and next practical steps. -- Best regards, Andrew Tropin