From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id MIc3IGr6+GF0BQEAgWs5BA (envelope-from ) for ; Tue, 01 Feb 2022 10:16:26 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id YAm2HGr6+GFxcAEAauVa8A (envelope-from ) for ; Tue, 01 Feb 2022 10:16:26 +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 4A3DC2B50B for ; Tue, 1 Feb 2022 10:16:25 +0100 (CET) Received: from localhost ([::1]:54570 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nEpGx-0005Zf-Nz for larch@yhetil.org; Tue, 01 Feb 2022 04:16:24 -0500 Received: from eggs.gnu.org ([209.51.188.92]:60190) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nEpGc-0005YJ-LN for guix-patches@gnu.org; Tue, 01 Feb 2022 04:16:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:48788) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nEpGc-0002zg-Af for guix-patches@gnu.org; Tue, 01 Feb 2022 04:16:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nEpGc-0007r6-7d for guix-patches@gnu.org; Tue, 01 Feb 2022 04:16:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#53466] [PATCH] home: Add redshift service. Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Tue, 01 Feb 2022 09:16: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: Andrew Tropin Cc: 53466@debbugs.gnu.org Received: via spool by 53466-submit@debbugs.gnu.org id=B53466.164370694930171 (code B ref 53466); Tue, 01 Feb 2022 09:16:02 +0000 Received: (at 53466) by debbugs.gnu.org; 1 Feb 2022 09:15:49 +0000 Received: from localhost ([127.0.0.1]:41691 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEpGP-0007qY-8V for submit@debbugs.gnu.org; Tue, 01 Feb 2022 04:15:49 -0500 Received: from hera.aquilenet.fr ([185.233.100.1]:52024) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEpGM-0007qI-BC for 53466@debbugs.gnu.org; Tue, 01 Feb 2022 04:15:47 -0500 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id E1C2B13D; Tue, 1 Feb 2022 10:15:39 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFgij8V-zs2z; Tue, 1 Feb 2022 10:15:39 +0100 (CET) Received: from ribbon (91-160-117-201.subs.proxad.net [91.160.117.201]) by hera.aquilenet.fr (Postfix) with ESMTPSA id A56AC4A; Tue, 1 Feb 2022 10:15:38 +0100 (CET) From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <20220123111159.27020-1-ludo@gnu.org> <87sft8tah0.fsf@trop.in> <87zgnfbtao.fsf@gnu.org> <87v8xzyddf.fsf@trop.in> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 13 =?UTF-8?Q?Pluvi=C3=B4se?= an 230 de la =?UTF-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Tue, 01 Feb 2022 10:15:38 +0100 In-Reply-To: <87v8xzyddf.fsf@trop.in> (Andrew Tropin's message of "Mon, 31 Jan 2022 21:22:04 +0300") Message-ID: <87v8xz54n9.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: / X-Rspamd-Server: hera X-Rspamd-Queue-Id: E1C2B13D X-Spamd-Result: default: False [-0.10 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] 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=1643706985; 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: content-transfer-encoding:content-transfer-encoding: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; bh=a/P9noh/Vvdxso5fu86At9EinzRQ8gXtoPqhUg9zrbU=; b=alahq4UPHkFlmjpksNI2L6YWXvSQG8PpoKxtvsWTchTpns/US7TxeMofJA8SK1pu8bkf+e LxxVtGKNgGpswPmGX2T5RD+tOStsTMBYffFJt83tqkRscFHbV5lxsfNOF0vBa1PxUQOEsW GT1sYhQgvxJ2gQ1jhIBkiyQf8GKhTkc0+1ALUCbSHpoZFTwQVnnJfTkbHrHlF/8PfWts9r 8r37+DdwnlXUW3w1U0ZlbiV69Gt8pWanKjqYsI/kzFrJzu35e94xpfwSSN77gPsFbs7zEd +CKfK+pfAv1YJ3jT8nWCKU7iWb8vixd/nlsVMMDUIzQo6cJGlSCwKoq0nKkI2A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1643706985; a=rsa-sha256; cv=none; b=DqxR2/sjuQsL6mX2iY3SmQacfJyasQh9loSUfi3fPgn4Oqr8l57zyONbWAD4BqW22FxVBV nsiiT0owdgMMJ2nFuXPTdYfQCxeVM3bkFLDoLsb1uRSXrjKbwfiGhPHyUtYeBGRjVdIuF0 cSfSzAX0KvIms/PUV4qqUyEyGvPDgofoiu8+X85NGG2Sg2NZ9ii/fyqybosWDWP+7zXC62 gJPyrNF7+IEbi76GpUWA0k03iSXYbGXOPXXONqYd57iA05Lrs1JWVDYkut9g2LR2W+Rvqb HwIcopeclNAJ3YLy5C9pA92SbHK20pIfnrTPSr33nUuPoQslkAua9ickNwDlqg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; 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: -3.63 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; 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: 4A3DC2B50B X-Spam-Score: -3.63 X-Migadu-Scanner: scn1.migadu.com X-TUID: Deh6mjNjsuuZ Hi Andrew, We=E2=80=99re drifting away from the practical issue of adding a Redshift service, but you raise interesting issues. 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 and= its handful of options, I see little incentive to go look at =E2=80=98man redsh= ift=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 convincing = compared to records, at least for our use case. [...] >>> 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 sys= tem >> services. > > Imagine terminal or almost any other user space program I=E2=80=99m not imagining: we=E2=80=99re discussing a very concrete service= 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 exception= (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 ~/.config,= but if some do, so be it. I=E2=80=99d say that the default should be to not ma= ke config available unless that=E2=80=99s required, just like what we do for s= ystem services. How does that sound? >> As for the latter, I thought about it but I=E2=80=99m not sure what it w= ould 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 prof= ile 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 lea= n on the side of not =E2=80=9Cpolluting=E2=80=9D the user=E2=80=99s profile, but= I can very well imagine that in other cases we=E2=80=99d prefer to extend the user=E2=80=99= s profile. >> I understand your concerns, but I think they=E2=80=99re beyond the scope= 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 actua= lly 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. > 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. :-) 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 configuration= trees. Thanks for your feedback, Ludo=E2=80=99.