On 2021-09-17 11:28, Xinglu Chen wrote: > On Thu, Sep 16 2021, Andrew Tropin wrote: > >>>> * Putting Home Services to ~(gnu services ...)~ >>>> In the thread https://issues.guix.gnu.org/49419#18 Ludovic suggested: >>>> >>>>> Regarding module names: what about putting everything in the (gnu >>>>> home …) name space. For services, I wonder if we could simply use >>>>> (gnu services home), for the essential services, and other (gnu >>>>> services …) module, but that assumes some code can be shared between >>>>> System and Home. Thoughts? >>>> >>>> ** Shortcomings >>>> While it's a nice idea, I see some shortcomings here: >>>> >>>> *** Code Reuse >>>> Mcron, Shepherd and a few other fundamental pieces are reused between >>>> Guix Home and Guix System, but it's easily done by exporting a few >>>> symbols from related modules. >>>> >>>> Records even for the same services have slightly different fields and >>>> because of macro nature can't be reused between Home and System >>>> services. In more details I mentioned this problem here: >>>> https://lists.sr.ht/~abcdw/rde-devel/%3C87y2cqifpx.fsf%40yoctocell.xyz%3E#%3c878s4l8kai....@trop.in%3E >>> >>> Some services might be useful to have in both Guix System and Guix Home; >>> for instance, Guix System currently has a service for configuring >>> Syncthing, and I think it makes sense to also have one for Guix Home, >>> this would mean that people not using Guix System (me :-)) could also >>> have Guix manage Syncthing. With the current approach, we would have to >>> copy and paste quite a bit of code, and if the Syncthing service for >>> Guix System changes, then the one for Guix Home might have to change as >>> well. >>> >> >> We can extract parts, which have to be in sync between home service and >> system service and just use them in both. I don't see how placing home >> service in the same module will decrease the amount of "copy-paste". >> >> If you talk about "shared" fields for configuration records, it's >> probably true, but I don't see any good solution yet. I'm unhappy that >> records are implemented with macros, because it complicates the >> extensibility of the mechanism, wrapping them in more macros doesn't >> make thing better IMO. > > Since we don’t have a way to avoid using macros for records, resisting > macros probably won’t really help much. :-) >
The fact that we already use them doesn't mean that we need to use more macros, IMO it's a good idea to keep the amount of macros as small as possible. >>> I have thought about a ‘define-configuration’ macro that would >>> generate one configuration record for Guix system and optionally, >>> one for Guix Home. For example >>> >>> (define-configuration syncthing-configuration >>> ...) >>> >>> would work as it currently does, and >>> >>> (define-configuration syncthing-configuration >>> ... >>> (home-service? #t)) >>> >>> would generate a <syncthing-configuration> record and a >>> <home-syncthing-configuration> record. >>> >>> There is the problem of <syncthing-configuration> and >>> <home-syncthing-configuration> not having the same fields. To solve >>> this, Each clause could have an ‘home-service?’ field, and the code >>> would look like >>> >>> (define-configuration syncthing-configuration >>> (package >>> (package syncthing) >>> "Syncthing package to use.") >>> (arguments >>> (list-of-strings ’()) >>> "Command line arguments to pass to the Syncthing package.") >>> (log-flags >>> (integer 0) >>> "Sum of logging flags.") >>> (user >>> (maybe-string 'disabled) >>> "The user as which the Syncthing service is to be run." >>> (home-service? #f)) ; not for Guix Home >>> (group >>> (string "users") >>> "The group as which the Syncthing service is to be run." >>> (home-service? #f)) ; likewise ^^ >>> (home >>> (maybe-string 'disabled) >>> "Common configuration and data directory.") >>> (home-service? #t)) >>> >>> This would mean that <syncthing-configuration> would have all the >>> fields, but <home-syncthing-configuration> would have all but the ‘user’ >>> and ‘group’ fields. >>> >>> We could also have a ‘define-home-configuration’ macro that would create >>> a <home-NAME-configuration> record and optionally, a >>> <NAME-configuration> record. Then ‘home-service?’ would be >>> ‘system-service?’ instead. >>> >>> Maybe it’s too complicated and not worth it, but it’s just an idea I >>> have had. >>> >> >> define-configuration is already a quite complicated macro, but maybe >> something like that will work, still unhappy with tons of macros for >> implementing records in scheme (: >> >>> >>>> The intersection of home and system services should be very low, so >>>> there is not much benifit here as well. >>> >>> Quite the opposite, I think it would be great if home and system >>> services could integrate more with each other. >> >> The system and home services can't really integrate with each other at >> least because of extension mechanism. >> >>> In NixOS, the NixOS modules and Home Manager modules feel like two >>> very distinct things, and it’s not really easy to share things between >>> them. >>> >> >> Yes, but with Guix System and Guix Home it's easier to keep them in sync >> and share code between them because they are both a part of the same >> repo. >> >> Going back to intersection: Yes, there are some services that are common >> to Guix Home and System: mcron, shepherd and maybe a few more, but most >> of the `guix system search .` is not relevant for user. >> >> Everything that can be implemented as a home service should implement >> as a home service in most cases. > > Not really sure what you mean by this, but the above proposal would > create a <NAME-configuration> and a <home-NAME-configuration> record. If something can be both home and system service we can prefer to implement home service, because it can be used on both Guix System and foreign distros. Yes, I got your idea. >> There are two case, where you can bring an argument against it, but >> I'll propose solutions upfront: >> >> - As admin I want to add a service in operating-system, but it's only >> available as a home service. >> >> I think we can do something like that: >> >> #+begin_src scheme >> (operating-system >> (services >> (list (service guix-home >> `(("USERNAME1" ,(generate-home-environment >> with-needed-services))))))) >> #+end_src >> >> - I want to start the home service on boot. >> >> Probably, something like linger systemd will be needed here for >> Shepherd, still seems very possible to implement. >> https://www.freedesktop.org/software/systemd/man/loginctl.html#enable-linger%20USER%E2%80%A6 > > That would be nice to have. > >> Yes, probably there are cases where we will need to have both system >> and home services, but I expect this number to be very low and >> everything else will fall in one category of services, this is what I >> mean by small intersection. As an exercise try to name 10 services, >> which doesn't belong to only one category. > > Well, there are quite a few that I can think of > > * The ones we have already mentioned: Mcron, Shepherd, and Syncthing. > > * Unattended-upgrade. > > * Rsync/state management. > > * guix-publish: As a normal user, I should be able to run a ‘guix > publish’ service, to share substitutes with others, without needing > root access. > > * Mail related services: Getmail/Fetchmail/Isync can be used by a normal > user for fetching their mail from some remote server. These programs > can also be used by a server that hosts a Patchwork instance to track > patches sent to a mailing list. I think this is what Christopher’s > Patchwork instance does. > > <https://patches.guix-patches.cbaines.net/project/guix-patches/list/> > > Dovecot/OpenSMTP/Exim can be used on a mail server, but they can also > be used as a local IMAP server, which something like Gnus can connect > to. > > I have also seen people use Postfix as a Sendmail/Msmtp replacement, > and it would thus make sense to have a Guix Home service for it too. > > * Alsa: There is already an Alsa service for Guix System, but a user may > also want like to configure their ~/.asoundrc file in order to not > pollute the system configuration. > > * WeeChat can be used as an IRC client, and as a relay for other WeeChat > clients to connect to. It would therefore make sense to have WeeChat > running on a server (Guix System), and then connect to it through > WeeChat as a regular user (Guix Home). > > * Shells: Each individual user will most likely configure their shell, > but the sysadmin also might want the configure the system-wide shell > and not just run with the default settings. > > There is also the problem of system service only working on Guix System, > whereas home services will work on foreign distros as well. As someone > who is on a foreign distro, I would like to configure things like Tor > (and Privoxy), Transmission, Ipfs, Bitlbee, and a login manager and a > desktop environment. But right now I have to be on Guix System to > configure to these things. > > That’s just the ones I can think of; other people probably have more > things to add. > I think most of this usecases are solvable by having only home services and linger shepherd. For example an administrator can define a home-environment in operating-system for weechat-relay user, which contains a WeeChat home service, configured as a relay and setup it with `guix system reconfigure`. Any other users can control their own home-environments and configure and install their weechat clients with `guix home` I see the downside that such processes won't be visible in root's herd, but as I already mentioned it doesn't seems to be a big problem and in addition, it is most likely solvable. >>> A while ago, someone on IRC mentioned that it would be nice to have >>> Mcron in Guix System run Mcron jobs that were specified in Guix Home. >>> The rationale is that Guix Home for a user will not activate---run >>> user Shepherd, thus running Mcron---until that user logs in. This >>> means that Bob’s Mcron jobs will only run when Bob is logged in. The >>> Mcron jobs in specified in Guix System will run regardless if the user >>> that those jobs belong to logs in. But if Bob wants their Mcron jobs >>> to run regardless if he logs in, he needs root access to be able to >>> add jobs to his Guix System config and run ‘guix system reconfigure’. >>> This does mean that the sysadmin has to add ‘mcron-service-type’ to >>> the ‘services’ field of the <operating-system> record, though. >>> >> >> Covered by linger idea mentioned above. The downside is it won't be >> visible in root's herd cli, but it also fixable either by extending >> shepherd or by using su to run herd from specific user. >> >>>> Utilitary functions like serialization helpers and so on can be >>>> declared in a shared module and reused between System and Home >>>> services. >>>> >>>> Recaping the section: All the necessarry code already reused, the >>>> future home/system services are not expected to share much code, >>>> different utilitary functions can be shared via (gnu services utils) >>>> or (gnu services configuration) modules. >>>> >>>> *** Confusion >>>> I already mentioned that I see a lot of confusion between System and >>>> Shepherd services and I expect some confusion between home and system >>>> services, it will be especially true if we place them in the same >>>> namespace. >>>> >>>> People will be trying to use home services inside operating systems, >>>> #+begin_src scheme >>>> (operating-system >>>> (services >>>> (list (service home-mcron-service-type ...)))) >>>> #+end_src >>>> >>>> and configuration record for system services inside home services. >>>> #+begin_src scheme >>>> (home-environment >>>> ... (service home-mcron-service-type >>>> (mcron-configuration ...))) >>>> #+end_src >>> >>> With the above proposal, the user would use ‘home-mcron-configuration’ >>> for home service, so I don’t think this should be a problem. And as >>> Maxime mentioned, we could have a ‘validate’ field which would give a >>> friendly error message if the wrong configuration record was given. >>> >>>> ** Summary >>>> Let's keep System and Home services separate for the sake of clarity, >>>> reuse code via shared modules or just exports in (gnu services ...). >>>> >>>> * Putting Home Services to ~(gnu home services ...)~ >>>> Another idea I saw is to move: >>>> ~(gnu home-services)~ -> ~(gnu home services)~ >>>> ~(gnu home-services gnupg)~ -> ~(gnu home services gnupg)~ >>>> ... >>>> >>>> Sounds reasonable, I'll just mention the ideas behind ~home-services~ >>>> name. >>>> >>>> System services have following naming conventions for the public API: >>>> >>>> in ~(gnu services CATEGORY)~ there are ~APP-service-type~, >>>> ~APP-configuration~ and other related symbols. >>>> >>>> Not to be confused, I decided to prefix all service types and >>>> configurations with ~home-~, so the exported symbols looks like: >>>> ~home-APP-service-type~ and ~home-APP-configuration~. >>>> >>>> The same rule applies for module names: We do the same way as system >>>> services do, but with ~home-~ prefix: ~(gnu services CATEGORY)~ for >>>> system, ~(gnu home-services CATEGORY)~ for home. >>>> >>>> All namespaces containing ~system~ now becomes ~home~: ~(gnu system)~ and >>>> ~(gnu home)~ respectively. >>>> >>>> I find such approach to be consistent and doesn't see to much reasons >>>> to change it. >>>> >>>> However, ~(gnu home services ...)~ also looks cool, but it would be a >>>> little inconsistent with system services, which will have one level of >>>> nestiness less: ~(gnu services)~. >>>> >>>> IMO, ~(gnu home services ...)~ would be a good choice if we use ~(gnu >>>> system services)~ for system services. >>> >>> Yeah, having both (gnu system service) and (gnu home service) could make >>> sense, but since we only have (gnu services), I don’t think it makes >>> much sense. >>> >> >> Just to clarify, by ..., I meant submodules, so it will be >> (gnu system services version-control) and >> (gnu home services version-control) for example. > > Sorry, I forgot to add ...; I meant (gnu system services ...) and (gnu > home services ...). > >> For now it's just: >> (gnu services version-control) and >> (gnu home-services version-control), which I find okeish. > > I would prefer to just have everything verson-control-related in (gnu > service version-control). Since everything is prefixed with ‘home-’, it > should make things clear that its used by Guix Home and not Guix System. Ok, got your opinion.
signature.asc
Description: PGP signature