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 ms9.migadu.com with LMTPS id 3onzOdRiTWT/zgAASxT56A (envelope-from ) for ; Sat, 29 Apr 2023 20:32:53 +0200 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 MGoOOdRiTWQ7uAAAauVa8A (envelope-from ) for ; Sat, 29 Apr 2023 20:32:52 +0200 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 753991D90 for ; Sat, 29 Apr 2023 20:32:52 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1psoIm-0001jZ-Tf; Sat, 29 Apr 2023 13:24:05 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1psoIk-0001fc-BW for bug-guix@gnu.org; Sat, 29 Apr 2023 13:24:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1psoIk-0003at-3B for bug-guix@gnu.org; Sat, 29 Apr 2023 13:24:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1psoIj-0000Ae-V0 for bug-guix@gnu.org; Sat, 29 Apr 2023 13:24:01 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#63082: [PATCH 14/17] services: mpd: Obsolete 'environment-variables' field. Resent-From: Bruno Victal Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 29 Apr 2023 17:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63082 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Maxim Cournoyer Cc: 63082@debbugs.gnu.org Received: via spool by 63082-submit@debbugs.gnu.org id=B63082.1682789021626 (code B ref 63082); Sat, 29 Apr 2023 17:24:01 +0000 Received: (at 63082) by debbugs.gnu.org; 29 Apr 2023 17:23:41 +0000 Received: from localhost ([127.0.0.1]:36609 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psoIP-0000A2-BY for submit@debbugs.gnu.org; Sat, 29 Apr 2023 13:23:41 -0400 Received: from smtpmciv1.myservices.hosting ([185.26.107.237]:57034) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psoIN-00009t-LM for 63082@debbugs.gnu.org; Sat, 29 Apr 2023 13:23:40 -0400 Received: from mail1.netim.hosting (unknown [185.26.106.173]) by smtpmciv1.myservices.hosting (Postfix) with ESMTP id 4312320987; Sat, 29 Apr 2023 19:23:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail1.netim.hosting (Postfix) with ESMTP id F040D80097; Sat, 29 Apr 2023 19:23:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail1.netim.hosting Received: from mail1.netim.hosting ([127.0.0.1]) by localhost (mail1-2.netim.hosting [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0SPTacBK25m2; Sat, 29 Apr 2023 19:23:34 +0200 (CEST) Received: from [192.168.1.239] (unknown [10.192.1.83]) (Authenticated sender: lumen@makinata.eu) by mail1.netim.hosting (Postfix) with ESMTPSA id 841FE80060; Sat, 29 Apr 2023 19:23:34 +0200 (CEST) Message-ID: <2e5d3ddb-5948-de11-4fa5-da02e848a8e6@makinata.eu> Date: Sat, 29 Apr 2023 18:23:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Content-Language: en-US References: <16e06b4b2a932a7c48696fcc1b89c5a454dc9d2b.1682690696.git.maxim.cournoyer@gmail.com> <2fabf610-5256-dad1-0e62-449fbcc738f0@makinata.eu> <874joyaad3.fsf@gmail.com> From: Bruno Victal In-Reply-To: <874joyaad3.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: bug-guix-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Seal: i=1; s=key1; d=yhetil.org; t=1682793172; a=rsa-sha256; cv=none; b=uPgPbxB9Hc2lZdN/SD4cZmnyy3qGahlz6ocvQjp+HiDV5sRSCX/JTqTfVYBgNRd3wPTY2e 9WdnV6564jnDL8hf/YtgzCwtoPRUOubvn7vW7+k4IzDvvFGq3fosgq6cgiL5TolZxuANUw N2yn3dspuQ+fv8ui6X/l3HuDkNN3Pjw4o4xKg2+z4I3KOmq9tT1VjxKepDrdKjOcgRaWyU qLTlmdAnKB9SMt0xrc9jf6h8rC+p2MV27SSemHgAJOjzL3WPDRHFTKBB2yQSsWGSwM2ye6 lme6yGjtSgk2fZf7uZyadyftWNGjfWuMjyzx3gdSjra7+YtycLZ0QtUW9cwX7A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1682793172; 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=lWCgWZXA+eEZFJWHuHloRO4rC4uXvEV093stZOU/Kvs=; b=Wvq2wp05LXqBIcrcjQNnSwRryPR/k/qEKz5BIu8vZzgNV7tTAAKBrxRhwav/6wZy1YnCuK L4g80gkNRx6Q4HcJ4L+UpOSy1uK4cikygRkRAUzCrOnLYH7Mu6aVb/g31A61r6xqGhZ75K Dk3rovr8Cp6nIIjm/q1P8tT46e14gQR7luRHrqUJIAIIW0SOQ1jyTz2WhIGKalbP/t6teA jhZxrDJzcBH6uWiHLrfo/ELGSTXpU6vblFF0WF7a7o+dwgpdMthqBYu3d4Iv450pN0+fL6 Ptnc1rpGoI0oHiyEh9sCYflCbGhs1jdingB08lXpyW2p6SsuXi8ozCDUuJfP1Q== X-Migadu-Scanner: scn1.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -1.70 X-Spam-Score: -1.70 X-Migadu-Queue-Id: 753991D90 X-TUID: akCf3tMAObXJ On 2023-04-29 18:04, Maxim Cournoyer wrote: > Hi Bruno, > > Bruno Victal writes: > >> On 2023-04-28 15:27, Maxim Cournoyer wrote: >>> Rationale: Services can be extended via the simple-service mechanism instead >>> of having to expose fields on service configurations that are not directly >>> connected to the service's configuration. >>> >>> * gnu/services/audio.scm (mpd-environment-variables-sanitizer): New sanitizer. >>> (mpd-configuration): Use it. >>> (mpd-shepherd-service): Hard code the useful environment variables inside the >>> Shepherd service. >>> --- >> >> This field shouldn't be deprecated as one of it's primary purposes is to allow for >> the pulseaudio daemon configuration to be set to another one. >> What you're doing here is effectively hardcoding the pulseaudio configuration. > > Our only means to declare a pulseaudio configuration > (pulseaudio-service-type) places it at this location, so it seems > reasonable to hard code it. What use case do you have for a custom > pulseaudio configuration that pulseaudio-service-type could not cater > to? This prevents users defining another environment variable and > forgetting to replace these, then wondering why the default pulse > configuration doesn't work, and it felt out of place to me (an > implementation detail better encapsulated). Indeed but note that there's a small subtlety to pulseaudio-service-type, chiefly that the service is not your typical ¿monodaemonic? process that is used throughout the system, rather it simply provides you a default config for the pulseaudio daemon. The fact that multiple pulseaudio daemons can be launched alongside is a strong indicator that perhaps you will want for some of them to use different configurations, which is done via the environment variables. Right now this would be mainly achieved using local-file, text-file or specifying a path but in theory the procedures for pulseaudio-service-type could be reused for serializing configurations to be used outside of the service. Regarding the users forgetting the variables, it looks obvious that if you omit the default values there then the behavior will also change accordingly. If you strongly feel that this is very pitfall prone (IMO it's no worse than forgetting to add %base-services at the end of the services field) then perhaps documenting it would suffice? > >> I'd consider this field to be within the same category as >> 'shepherd-requirement', it's for flexibility > > I like the idea of more flexibility, but I don't like that these fields > need to be duplicated for each service, somewhat encumbering the view. > Perhaps we need to devise some 'always nice to have' set that would be > configurable for any service without having to expose these fields as > part of their main configuration? > Right, it's not optimal but these are fields with legitimate uses, instituting rigidity here will simply make the services overly opinionated to some particular kind of setup, which drastically reduces their value. Regarding their duplication, perhaps an improvement for define-record-type* would be better? SRFI-136 seems something that would address these concerns.