From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id WG0UKwsw+mEEFQEAgWs5BA (envelope-from ) for ; Wed, 02 Feb 2022 08:17:31 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id aAyWJwsw+mFSLAEAauVa8A (envelope-from ) for ; Wed, 02 Feb 2022 08:17:31 +0100 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 20A1932743 for ; Wed, 2 Feb 2022 08:17:31 +0100 (CET) Received: from localhost ([::1]:52692 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nF9tQ-0001Kp-V2 for larch@yhetil.org; Wed, 02 Feb 2022 02:17:28 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58102) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nF9dU-0006aE-DM for guix-patches@gnu.org; Wed, 02 Feb 2022 02:01:44 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:57372) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nF9cY-0005t7-9R for guix-patches@gnu.org; Wed, 02 Feb 2022 02:00:03 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nF9cY-0006Pm-4w for guix-patches@gnu.org; Wed, 02 Feb 2022 02:00:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#53466] [PATCH] home: Add redshift service. Resent-From: Andrew Tropin Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Wed, 02 Feb 2022 07:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53466 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 53466@debbugs.gnu.org Received: via spool by 53466-submit@debbugs.gnu.org id=B53466.164378516424569 (code B ref 53466); Wed, 02 Feb 2022 07:00:02 +0000 Received: (at 53466) by debbugs.gnu.org; 2 Feb 2022 06:59:24 +0000 Received: from localhost ([127.0.0.1]:51269 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nF9bw-0006OB-6s for submit@debbugs.gnu.org; Wed, 02 Feb 2022 01:59:24 -0500 Received: from mail-lj1-f170.google.com ([209.85.208.170]:33356) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nF9bt-0006Nw-Hj for 53466@debbugs.gnu.org; Wed, 02 Feb 2022 01:59:22 -0500 Received: by mail-lj1-f170.google.com with SMTP id bx31so15793923ljb.0 for <53466@debbugs.gnu.org>; Tue, 01 Feb 2022 22:59:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=trop-in.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=6VMVI6BWUmFtCisI7OWsDNdRskjyYmYs6a0mPPukxz4=; b=m0SuCV6wjOdncqpsKlCYpvoDFnEi71BqfEQp8VowUUDUpiVdJK/yTQ8EzuRPFj/quF rC5zfaoKzRuX7zgxaZ7icNCol5x5jaLCFZLnhSYcTOHr738jnwLpYyfoUIEPnoNAxsRH mhUTmxz6wMCNfol5bSLTfw1WUJkis2jlNJNPw/+5KThtKjI2ObSoZ9g8PxtEsT/6xd8S ZyfvomVAfa97yaX18NlqKg3Q+QpgvmdyhiW3JwWh4HeZuQf/34cN3lu/VYOsha4PAxrB m4Jv32Zxhu59Iiye8m4amC8xkP5e8jWJnKfuWGECdmpR40hEF3+buWAs7BOLXrGoKuMa 0GHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=6VMVI6BWUmFtCisI7OWsDNdRskjyYmYs6a0mPPukxz4=; b=veq9UjZ9pniWb1Ak7eIxwIXpLHGQMk4WD/M+TmY8xPEmgF2wNrzBc51dk1uaJDF6gp Vlwon7UBp2rT9jNqpN7HspWfm64nO/rZStLSb/bWaNhxlrLcZjeel1SdCPuCyBoOKPQq /4ilBOASt6X/9/LE7icX1hfcTEmrSGwO/dDEHGJYSc71Obb7BziiYkTXXTlI9YUXlPzC dov0v22YwS3M3QdJVkOOkyDZVjciLXAozx4sm4r41nyiJEONROpVpNQ2TmipmtXMHKVa sF5otWkL8yY61WguuT2mEY7LeVo3TLNUECdMAhNKs/cUYFLQQt/dkH9cjLtDTc2Fg2i6 8XIg== X-Gm-Message-State: AOAM5328UV/c6t/6Hydl5H73vqLOl3psBMHJpO4RjBUvHcSKO8rij+7L PH95DwWFMG66wRPN8E+ccjheqQ03LALGig== X-Google-Smtp-Source: ABdhPJyLPhC1RB5HMhYWd/5hF/QjipJe+bTiwBwCcgfT8DIESgxqRoTsAD3jd2yLkHeJ7392YoDD7Q== X-Received: by 2002:a2e:9f41:: with SMTP id v1mr18805701ljk.154.1643785155200; Tue, 01 Feb 2022 22:59:15 -0800 (PST) Received: from localhost (109-252-135-33.dynamic.spd-mgts.ru. [109.252.135.33]) by smtp.gmail.com with ESMTPSA id p15sm3109499ljn.19.2022.02.01.22.59.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Feb 2022 22:59:14 -0800 (PST) From: Andrew Tropin In-Reply-To: <87v8xz54n9.fsf@gnu.org> References: <20220123111159.27020-1-ludo@gnu.org> <87sft8tah0.fsf@trop.in> <87zgnfbtao.fsf@gnu.org> <87v8xzyddf.fsf@trop.in> <87v8xz54n9.fsf@gnu.org> Date: Wed, 02 Feb 2022 09:59:11 +0300 Message-ID: <87fsp1zrcw.fsf@trop.in> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1643786251; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:resent-cc:resent-from:resent-sender: resent-message-id:in-reply-to:in-reply-to:references:references: list-id:list-help:list-unsubscribe:list-subscribe:list-post: dkim-signature; bh=6VMVI6BWUmFtCisI7OWsDNdRskjyYmYs6a0mPPukxz4=; b=FwgchdDqoOixPJtoqAB4br7X9LmH/A+p/oINBZ67Oh8yC8Ycbw5kEAO6bj2XBq95K3Cpw8 aLdolzpC9yp96Kr5sVDdowt2P5kC5KjfRQvUcRRssmc/eN+p43FZGJvd9WwZVgGV2aJbk+ u2+xs7C8FYr0z7g0uUIUambnXMZHbn9kzNzhTseXYDG+0mQGHXASkhMCCalwuM7wOwzLkp 0GT5NeYwVD6+P8IP6hyzXCf8l63M/1Ra6ONTbWj0eCl/QLZnh8Ugmx9m0UZgePOdnhLcT9 MT+WpVUTzj7yK+ZajyHCCBnCQVQlPjPMehTwZGhKmD/dqMkV4AufjPx4XBvV7A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1643786251; a=rsa-sha256; cv=none; b=qiFdv6L42HGZnGukyilbzrr3f9cfowdgZcne2HnWQ+tgTZqoswmyCbm7cyIBHcxihMn3Yx E5vpkxcj7sZrTmi9LJU8f0gDtMJSXDfdrU6V3vPNP3c/DwKB+Wtv5C0eAXeuYPkp6F4Ryv 83xf5lky6rDJZVZtdMhBJU9SJAQGisZTn9h8CV7zmaHlW/T8T+ErDr4Fy6MNFrWhUdpVSi qUHnIPWgOzRl/y0IQ0K154/L8rix5q8QVyvfa5QVCJwRRsasx6I+3dAvo9bBX+HZHYMUeM 3nQ38ddZ248WkX0TmagmNA5G5U9KkwkOuLD3CIl4Ps5FHT31ixFYGf1hQV2J2Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=trop-in.20210112.gappssmtp.com header.s=20210112 header.b=m0SuCV6w; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -5.03 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=trop-in.20210112.gappssmtp.com header.s=20210112 header.b=m0SuCV6w; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 20A1932743 X-Spam-Score: -5.03 X-Migadu-Scanner: scn0.migadu.com X-TUID: kDPst7w7dbVk --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2022-02-01 10:15, Ludovic Court=C3=A8s wrote: > Hi Andrew, > > We=E2=80=99re drifting away from the practical issue of adding a Redshift > service, but you raise interesting issues. That's true, but a few first home services will set the tone for the rest, so it's probably a good idea to look ahead right now, then later. > > Andrew Tropin skribis: > > [...] > >>> Yes, that=E2=80=99s the usual tradeoff. The choice made so far in Guix= has been >>> to choose clarity over faithfulness to upstream=E2=80=99s name choices. >>> >> >> Maybe I'm wrong, but it's very likely that most of the users will be >> checking out upstream documentation anyway during configuration of some >> programs and those renamings will bring a lot of confusion and >> especially, when the record fields names will be combined with names in >> escape hatches. > > I think there doesn=E2=80=99t have to be a single answer. For Redshift a= nd its > handful of options, I see little incentive to go look at =E2=80=98man red= shift=E2=80=99; > it doesn=E2=80=99t add much to what we provide. > > For more complex services, the answer might be different, although again > the Dovecot service shows that, even for this big a service, we can > provide comprehensive bindings and associated documentation. > > [...] > >>> I can see the appeal of alists, but the choice made in Guix is to use >>> records for configuration; that has advantages, such as type checking, >>> detection of incorrect field names, and the ability to use all the bells >>> and whistles of (guix records). >> >> Type checks are possible with data structure driven approach as well and >> in a fact it's much more flexible and powerful, however to be fair it >> will require some work to prepare a good framework for that like >> https://github.com/plumatic/schema >> or >> https://github.com/metosin/spec-tools/blob/master/docs/02_data_specs.md >> for Clojure. >> >> It's also possible to generate documentation for such specs. >> >> Potentially, such approach is more powerful. > > I=E2=80=99m aware of Clojure specs, but I don=E2=80=99t find it convincin= g compared to > records, at least for our use case. > Ok. >>>> It would be good to extend home-files-service-type with config-file >>>> generated above and home-profile-service-type with the value of >>>> `redshift` field. >>> >>> Regarding the former, that=E2=80=99s not something we usually do for sy= stem >>> services. >> >> Imagine terminal or almost any other user space program > > I=E2=80=99m not imagining: we=E2=80=99re discussing a very concrete servi= ce here. :-) > > For Redshift, I don=E2=80=99t see the point of making the config available > globally. For system services, there=E2=80=99s only a handful of excepti= on (PAM > and OpenSSH come to mind, but see /etc). > > Again, there doesn=E2=80=99t have to be a single answer. I suspect many > services won=E2=80=99t need to make their config available under ~/.confi= g, but > if some do, so be it. I=E2=80=99d say that the default should be to not = make > config available unless that=E2=80=99s required, just like what we do for= system > services. > > How does that sound? It sounds logical for redshift, but inconsistent in general: some home services install package to profile, some not, some create config in XDG_CONFIG_DIR, some not. I still think that almost all services must provide both package and configs. >>> As for the latter, I thought about it but I=E2=80=99m not sure what it = would be >>> used for. WDYT? >>> >> >> It can be used for debugging, for man pages or when redshift don't use >> shepherd service and started in different way (by wm for example). > > The point of this Redshift service is to have it started automatically, > so to me the only reason to add =E2=80=98redshift=E2=80=99 to the user pr= ofile would be > to allow =E2=80=98man redshift=E2=80=99. > > I don=E2=80=99t view it as super useful in this case, and would instead l= ean on > the side of not =E2=80=9Cpolluting=E2=80=9D the user=E2=80=99s profile, b= ut I can very well > imagine that in other cases we=E2=80=99d prefer to extend the user=E2=80= =99s profile. > >>> I understand your concerns, but I think they=E2=80=99re beyond the scop= e of this >>> review. I also think that there=E2=80=99s ample experience with system= services >>> showing that writing =E2=80=9Cnice=E2=80=9D configuration bindings actu= ally works in >>> practice. >> >> I saw how well-written, but macros-based solutions in Clojure ecosystem >> slowly died and substituted with data-based. I understand that Guile >> ecosystem has a slightly weaker toolkit for processing datastructures, >> but by the end of the day I think we will be here sooner or later. >> Using macros instead of datastructures feels for me like remaking the > > Records are data structures, not macros. > But, IIRC, define-configuration, define-record-type are. >> same mistake again knowing the consequences. Maybe I'm wrong. > > Maybe one of us is wrong, or maybe it=E2=80=99s more complex than this. = :-) Also, maybe my non-guile experience doesn't apply here. > > As it turns out, I find Guix=E2=80=99s configuration records rather nice = to > use=E2=80=94much nicer than, for example, Gnus=E2=80=99 loose configurati= on trees. Unfortunately, I'm not familiar with Gnus internals and can't say if it's related, similar or not. =2D-=20 Best regards, Andrew Tropin --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJDBAEBCgAtFiEEKEGaxlA4dEDH6S/6IgjSCVjB3rAFAmH6K78PHGFuZHJld0B0 cm9wLmluAAoJECII0glYwd6wi8cP/jUbawgZB2j7UUyN3b7GedLqCEQyPKqJBwwY OlwCIT+t8BADpMWvbHeXdZze69N8Dq0LZSBYzO4SkX615Y+m7h5P4Y+fN9gCip7W QYcXuupMAwwiS+H36r10AQrhdLaWpkP81JGmhrOJ3NfdYbOu6nmuLu+UyK1+8FUy hvBG/Q568heBcA6y8QgMtr052EJpu1IlBZ5kYxI7EKZjoA3LN8FINKkijH1GZNw3 1Zxp6c1OLAGAQJ0eV9jrjHKKDpiSvcGozaKaU6xtLdfdvkhfhTS5KBac+Rc5N20Y siXWeHCzz5XqVRi7VMNM9FEQl8BE0UdDgpOGVmS4JHb3HOM87MfVZWZc+EalVWVF biM8bQlXxH31EascJwJcrdJ8N6QBP4L3VK//XMi+7Qj7mNmoSqvE1dEuGMiGuR9l ViW+uuY6BKRJF2LEj69VOEwnIkkNKO+s9kkOMQiOAbsi46meCzAo5V22KMbvmgS7 oWB+drg/UIb2zyDsW8O+AQnlcnhwfEx/FUfz6f6J9lV43fsHdQXWr4uBu4dO/2dy 9MnYFzXVxP4/ckx1keCPj1kfA2SKctNIw3NSxGNKJP62TtfwO04dK3tJPbMhgyBA 9uvUttazmY3ABs/XekjuPYSEA7Oo9Dgt512xA2ARQRYPo/Iel/VGZjgbEnAtiUwU IjPGFgjA =A+fP -----END PGP SIGNATURE----- --=-=-=--