From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id IC19Nfi8UWRkRQAASxT56A (envelope-from ) for ; Wed, 03 May 2023 03:46:32 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 4AySNfi8UWQvbAAA9RJhRA (envelope-from ) for ; Wed, 03 May 2023 03:46:32 +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 861D33FB1A for ; Wed, 3 May 2023 03:46:27 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pu1ZF-00043o-7G; Tue, 02 May 2023 21:46: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 1pu1ZC-00043Q-K4 for bug-guix@gnu.org; Tue, 02 May 2023 21:46: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 1pu1ZC-0008IM-Ah for bug-guix@gnu.org; Tue, 02 May 2023 21:46:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pu1ZB-0005O0-RX for bug-guix@gnu.org; Tue, 02 May 2023 21:46:01 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#63082: [PATCH 14/17] services: mpd: Obsolete 'environment-variables' field. Resent-From: Maxim Cournoyer Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Wed, 03 May 2023 01:46: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: Bruno Victal Cc: 63082@debbugs.gnu.org Received: via spool by 63082-submit@debbugs.gnu.org id=B63082.168307831120632 (code B ref 63082); Wed, 03 May 2023 01:46:01 +0000 Received: (at 63082) by debbugs.gnu.org; 3 May 2023 01:45:11 +0000 Received: from localhost ([127.0.0.1]:45302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pu1YN-0005Mh-0w for submit@debbugs.gnu.org; Tue, 02 May 2023 21:45:11 -0400 Received: from mail-qv1-f43.google.com ([209.85.219.43]:57363) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pu1YJ-0005M9-2v for 63082@debbugs.gnu.org; Tue, 02 May 2023 21:45:09 -0400 Received: by mail-qv1-f43.google.com with SMTP id 6a1803df08f44-5f3da4f91a0so21341586d6.2 for <63082@debbugs.gnu.org>; Tue, 02 May 2023 18:45:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683078301; x=1685670301; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to; bh=oBAqAZ8FWSwymMRTBOJ34ta5iUCpke+gZ0yVUWjzUFo=; b=IFD5bhneIqqOnIFEuBngrvqdBD+6BvnIKcpXU7nh9sd4BjHWhdblJNte4UYdupsDJy /fbWzh9MTKO+ENzh59649FF8SI36r0kEZmcErb5u2PGoJ5L0pKa+jYntycmrvT4KY+DD LpFOhCZTQ5rScQMHHjp9nqOc3M7VIch49gGWpbQkvW4JOZzhcCa0zbuyD/GcAgwczZZB 4PhvSYThMdEex8TNyZIheqKRsHcndoTWdqsLYPMcrMZmOZ+GGu3KApPoBkZqXFtaMB4S CxplFE+tpNLjYKx6E3n+BsNfNX4jmytFJ9jXbzR/9Z6hXBf1WtVV78kKuPxqEBhGCCaI PM1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683078301; x=1685670301; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=oBAqAZ8FWSwymMRTBOJ34ta5iUCpke+gZ0yVUWjzUFo=; b=FjO8UfrQIAm4BZYTZokywGkUUy5/eLCTSasiU45AP+2SHSLs/iCIAIYAUiLRTHvLE6 8chaqPpOZ6FvvtMN4iNWYtXgn9Lut9dckw3BiR1t7QcE39wtBZrT09e4i5EGh4A7N9T+ tWAcNS8gBToJIE49nUgD0CvGZR/iy9oBr0J9k5BhvD31H5U8swL+F77s7f2wJuojZRQ3 zsxrsakedBiDeEYOsGOJZVAZnYaKxjqebyQTldggzieIuqxTe+tO8zt2ZPBC8pJ2UNDI 8yc29JDpoBnRw/uHyCvDNx30o3ZdWEEPfGPrv9KEc1F9S21as/QEQyxUOWRcgHUwX8tB oycw== X-Gm-Message-State: AC+VfDxufyceDSy3blDwmKDHL0nfJPpQVUtCq4jCGX2mhOfPVV9vI0Ox j7BOHPQ5wQlgNtuh7lvo8h0m8W11s2jzAw== X-Google-Smtp-Source: ACHHUZ4l8CgLcOz5MC2W7Xe99Az1I4xvV1SjfqZywvTq1vU9FuYtUqt2Q6t2rqPtyHgnGSOaURkwlw== X-Received: by 2002:a05:6214:246a:b0:5ef:59d1:8d14 with SMTP id im10-20020a056214246a00b005ef59d18d14mr8614652qvb.2.1683078301016; Tue, 02 May 2023 18:45:01 -0700 (PDT) Received: from hurd (dsl-157-118.b2b2c.ca. [66.158.157.118]) by smtp.gmail.com with ESMTPSA id b19-20020a05620a089300b0074de92520b1sm10099744qka.83.2023.05.02.18.45.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 May 2023 18:45:00 -0700 (PDT) From: Maxim Cournoyer References: <16e06b4b2a932a7c48696fcc1b89c5a454dc9d2b.1682690696.git.maxim.cournoyer@gmail.com> <2fabf610-5256-dad1-0e62-449fbcc738f0@makinata.eu> <874joyaad3.fsf@gmail.com> <2e5d3ddb-5948-de11-4fa5-da02e848a8e6@makinata.eu> Date: Tue, 02 May 2023 21:44:59 -0400 In-Reply-To: <2e5d3ddb-5948-de11-4fa5-da02e848a8e6@makinata.eu> (Bruno Victal's message of "Sat, 29 Apr 2023 18:23:34 +0100") Message-ID: <87h6su1944.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 X-Migadu-Scanner: scn1.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20221208 header.b=IFD5bhne; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=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: 5.80 X-Spam-Score: 5.80 X-Migadu-Queue-Id: 861D33FB1A X-TUID: 5Jn87d8iDvSn Hi Bruno, Bruno Victal writes: > On 2023-04-29 18:04, Maxim Cournoyer wrote: >> Hi Bruno, >>=20 >> Bruno Victal writes: >>=20 >>> On 2023-04-28 15:27, Maxim Cournoyer wrote: >>>> Rationale: Services can be extended via the simple-service mechanism i= nstead >>>> of having to expose fields on service configurations that are not dire= ctly >>>> connected to the service's configuration. >>>> >>>> * gnu/services/audio.scm (mpd-environment-variables-sanitizer): New sa= nitizer. >>>> (mpd-configuration): Use it. >>>> (mpd-shepherd-service): Hard code the useful environment variables ins= ide the >>>> Shepherd service. >>>> --- >>> >>> This field shouldn't be deprecated as one of it's primary purposes is t= o allow for >>> the pulseaudio daemon configuration to be set to another one. >>> What you're doing here is effectively hardcoding the pulseaudio configu= ration. >>=20 >> 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 =C2=BFmonodaemonic? 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, w= hich is done via the > environment variables. > > Right now this would be mainly achieved using local-file, text-file or sp= ecifying 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 yo= u 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 t= han forgetting to add %base-services > at the end of the services field) then perhaps documenting it would suffi= ce? Is this a use case in actual use? It seems a bit of a stretch in my mind, especially considering the service was already difficult to get working in its default configuration; I doubt someone would go out of their way to manage multiple distinctly configured pulseaudio daemons :-). But if it's something in actual use providing value, I don't mind to keep it until we have a better way to extend a common set of basic properties for services in general. >>> I'd consider this field to be within the same category as >>> 'shepherd-requirement', it's for flexibility >>=20 >> 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? >>=20 > > Right, it's not optimal but these are fields with legitimate uses, instit= uting rigidity here will simply > make the services overly opinionated to some particular kind of setup, wh= ich drastically reduces their value. > > Regarding their duplication, perhaps an improvement for define-record-typ= e* would be better? > SRFI-136 seems something that would address these concerns. I've yet to look carefully into SRFI-136 would provide us with, but it seems an interesting direction, to the sound of it. --=20 Thanks, Maxim