From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id wNe8I2nwQWHloQAAgWs5BA (envelope-from ) for ; Wed, 15 Sep 2021 15:08:57 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id 2KKiHmnwQWFgRAAAbx9fmQ (envelope-from ) for ; Wed, 15 Sep 2021 13:08:57 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 9F1B0922 for ; Wed, 15 Sep 2021 15:08:56 +0200 (CEST) Received: from localhost ([::1]:48602 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mQUel-00046A-JV for larch@yhetil.org; Wed, 15 Sep 2021 09:08:55 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46808) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQUd7-0002lP-SX for guix-devel@gnu.org; Wed, 15 Sep 2021 09:07:13 -0400 Received: from h87-96-130-155.cust.a3fiber.se ([87.96.130.155]:48882 helo=mail.yoctocell.xyz) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQUd2-0006CZ-Vh for guix-devel@gnu.org; Wed, 15 Sep 2021 09:07:13 -0400 From: Xinglu Chen DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yoctocell.xyz; s=mail; t=1631711221; bh=rtpeM1f/VBulxS8XVPRYy3ZWfCFp/cbBs1SzyTAVsq0=; h=From:To:Subject:In-Reply-To:References:Date; b=sqKHPBiVIy/Xv6DYO3GNHz7h3BAzPHMNkZO6c+55muCXV0ZvVQQDYC8KBvvxlvuMh N2OMvwpykyoek25hnMpE6zgPWL43Swu+gY9HhB5rtRMq2uOB9hCVrRPcd2ZArmp4LJ RSobwEy4AgsGVx7NwjQDIj+ZmMCdb+7B5AnzKSm0= To: Andrew Tropin , guix-devel@gnu.org Subject: Re: On the naming of System and Home services modules. In-Reply-To: <87zgsei5ta.fsf@trop.in> References: <87zgsei5ta.fsf@trop.in> Date: Wed, 15 Sep 2021 15:06:58 +0200 Message-ID: <87pmtarnrh.fsf@yoctocell.xyz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Received-SPF: pass client-ip=87.96.130.155; envelope-from=public@yoctocell.xyz; helo=mail.yoctocell.xyz X-Spam_score_int: 14 X-Spam_score: 1.4 X-Spam_bar: + X-Spam_report: (1.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_SUSPICIOUS_NTLD=0.5, PDS_OTHER_BAD_TLD=1.999, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1631711336; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=+2hTrgi+N1XVDv8i5ZsJj719q6jnScnu5tytcKLcUZ8=; b=V7wQroVOhVOPcitxiA4yH1gpVt1TJeJGjkdZLjuGpf+lpqscO/ego2ThDo1YUVjyfk8QWg 58v9HpLky7gBS+fuJKD11N/GVvCHY6p9LznvdjsahxbNGMnuEUmjflQ7Edc0xaVNmgmV2c y2AfzHfK3JG4HbeyvZNR9G/2wk3m0cqWqHJuij3JFVtFn9MReywVJLqxyFttYA/eIykhqE MoaN44c/iOg1UeGU7axdW1WCn+4l3bH6hZ+DR1bWjJCcb+eCLDOsjPJX0m5HssHe/Vk6HT wqM5OUcssUFBz51sbEJI2E7/D9/KaJb58wigA/2HsdDQr5OcxQgvS5mE9r6jxQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1631711336; a=rsa-sha256; cv=none; b=QSqCxMvmcYRJgLP++CKvIZNFojHwymnHChIn5Rx/zArCzdNqGmVj2fM8RIGyKKZ01RQNgH EeUeGDmxc/Inz5ZzmC/7HsG9/6r4NH/kFg21LeYJyZJRj8mkYK48iji7Ri6RKwXhmTjNs9 raB46f8imEoXdrzIDSfE6Pw6GyROYYL+okoIOF33fV+0769q6/c+/C/3wukklYiGKyWHiB 0TsPhk7pp6oHGb44+wp7KrmcO8WaWxPlZ32ztt0x9n98B04W903Zrb5JZq6DXZRDp+1qEO OwOrzrdpHpa8kXFdpIHXxrSAb314k+9QnH60V58JkLIEUmuKOGUxAUjq1w5tTg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=yoctocell.xyz header.s=mail header.b=sqKHPBiV; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -3.70 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=yoctocell.xyz header.s=mail header.b=sqKHPBiV; dmarc=pass (policy=none) header.from=yoctocell.xyz; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 9F1B0922 X-Spam-Score: -3.70 X-Migadu-Scanner: scn1.migadu.com X-TUID: k8SJeWUo5ac9 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Sep 15 2021, Andrew Tropin wrote: > This topic was raised a few times during development of Guix Home > project and also during the review of wip-guix-home branch. I made a > separate thread to do an exhaustive discussion of it. > > * Services and Confusion > It's an optional section, you can skip it, but I still find it somehow > related to the topic. > > I want to re-raise the issue related to system services concept. When > I started using Guix I found system services to be confusing, > originally I thought it's a way to declare services managed by init > system, but later I realised that only some of system services becomes > Shepherd services and many of them doesn't. It's not a unique problem > I see this issue appear again and again in different Guix chats and > communities. > > - System services :: just building blocks, nodes of DAG representing > a system, which after folding, results in a complete operating system > or other artifact. > - Shepherd services :: long-living processes/daemons managed by init > system or user-space Shepherd. It's what people used to refer as services. > > It will be very hard and costly to rename system services to something > less confusing, but at least let's try to keep those concepts as > distinct as possible. Probably originally system and Shepherd > services were closely related, but not now, so let's express it very > clearly in docs/chats/mailing lists. > > Another player on this field is "home services", which is a similar to > system services, but used for describing a separate DAG, which after > folding, results in home environment (artifact containing user's > program configurations and profile with packages declared by user). > > * 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 =E2=80=A6) name space. For services, I wonder if we could simply u= se >> (gnu services home), for the essential services, and other (gnu >> services =E2=80=A6) module, but that assumes some code can be shared bet= ween >> 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.fsf@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. I have thought about a =E2=80=98define-configuration=E2=80=99 macro that wo= uld 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 record and a record. There is the problem of and not having the same fields. To solve this, Each clause could have an =E2=80=98home-service?=E2=80=99 field, and = the code would look like (define-configuration syncthing-configuration (package (package syncthing) "Syncthing package to use.") (arguments (list-of-strings =E2=80=99()) "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 would have all the fields, but would have all but the =E2=80=98= user=E2=80=99 and =E2=80=98group=E2=80=99 fields. We could also have a =E2=80=98define-home-configuration=E2=80=99 macro that= would create a record and optionally, a record. Then =E2=80=98home-service?=E2=80=99 would be =E2=80=98system-service?=E2=80=99 instead. Maybe it=E2=80=99s too complicated and not worth it, but it=E2=80=99s just = an idea I have had. > 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. In NixOS, the NixOS modules and Home Manager modules feel like two very distinct things, and it=E2=80=99s not really easy to share things between them. 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=E2=80=99s Mcron jobs will only run when Bob is logged in. The Mcron jo= bs 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 =E2=80=98guix system reconfigure=E2=80=99. This does= mean that the sysadmin has to add =E2=80=98mcron-service-type=E2=80=99 to the =E2=80= =98services=E2=80=99 field of the record, though. > 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 =E2=80=98home-mcron-configurati= on=E2=80=99 for home service, so I don=E2=80=99t think this should be a problem. And as Maxime mentioned, we could have a =E2=80=98validate=E2=80=99 field which wo= uld 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=E2=80=99t think it makes much sense. > * Conclusion > I'm quite satisfied with current state of naming, but probably I miss > some points and, also, maybe there are some other good or even better > naming schemes. In case there is a better naming approach, we can > decide on using it, It would be not an easy change, but until > wip-guix-home branch is not merged, it still easier to do this than do > it later. > > LMKWYT. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJJBAEBCAAzFiEEAVhh4yyK5+SEykIzrPUJmaL7XHkFAmFB7/IVHHB1YmxpY0B5 b2N0b2NlbGwueHl6AAoJEKz1CZmi+1x5VeoP/3562z2yw4Uvb+8T2bv8C0+Lsvgt p2EbfEz2BjTz/Z0FG+yYBAhX1LQFVt66qPGinK2FL0SurcbzVUAcLhkW/TqktY4k CcfH+NBbSZc5WSX4yj9350A5Ur/Vr9xjF5EX/WqgWcodqsOVBPqa4faXCZ7iVhun gCxNAITjxtutuKiRnNU7NJy7z92rPGJg0Vb6BG08VWmmR/cYMCV5+xvdneGIFX0r +wh5uQQA3Pl+LDvZ3Vvq2PiRuHnOsWOaYKRIG7LSXG10+65g8cswW3GSm8bOVOOl kL6RThdMaHU/iAO4FCyco4gvdXAjt7FB26uOOEmo/U5lsv8GStnDhUhIlZsd+InY 8q/GOVrgLhILwDvHumBUKBOlxVTEzu9apNVfgHVhYWzQMlp5Jg1zoCTfsGlUt008 b6s5Z0LnEMOa9Y+l9o5aSt9qpH2d+XBjFStbl8geXK1pECetXzjCQ50/4Ot5H4ft UtTH9f4DKyJqAnjXeIpMq1+At0n3sZKCkhnXF1nX9RHRpjCg4XAZ1iKzV6yg4xGP AYHjBIwreR4MLF4IImM3nl1kqZdVFtDSdS7eHK3sehv1VHGSz84vVVENRh4mjxkT WOIDo+VxgbOy9Zus/iqtEf3LGblXudu2zKv9NXTz960r8O/eOqQsfyQSl3UqlNSQ u1TEETntKs/ypupe =BbR8 -----END PGP SIGNATURE----- --=-=-=--