From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id 4GxeO4fdj2Jf2wAAbAwnHQ (envelope-from ) for ; Thu, 26 May 2022 22:05:28 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id KKeCOofdj2L2YQAAG6o9tA (envelope-from ) for ; Thu, 26 May 2022 22:05:27 +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 7CE9DE0F9 for ; Thu, 26 May 2022 22:05:27 +0200 (CEST) Received: from localhost ([::1]:53138 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nuJja-00059W-H2 for larch@yhetil.org; Thu, 26 May 2022 16:05:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37930) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nuJhz-0003N5-5A for guix-devel@gnu.org; Thu, 26 May 2022 16:03:47 -0400 Received: from mail-ed1-x544.google.com ([2a00:1450:4864:20::544]:34495) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nuJhw-0001rd-RX for guix-devel@gnu.org; Thu, 26 May 2022 16:03:46 -0400 Received: by mail-ed1-x544.google.com with SMTP id o28so3072759edi.1 for ; Thu, 26 May 2022 13:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=4jIbEBRomxYAKZxpKkf0ZM3dSAusy77ln8vzjtKtO2o=; b=Jcjzgl2EueGMMSRtBmRs7mJsA8POI0UKDQUQqEb/GCOMGvTgVJm9/FjOyAFMyJtp5Z x/xEWyIR9S5cJNIwEkJAFWol8IIj8BlEYKYw+NF5L4b0k/VW5cHQJU2Oz1Xe3+OkImvd Nql461xfTRKOOp2JyTnSruuY4zcxh2tmk18da5N91w72T1SCzglEhSAaMhhWexQ2svUl 3chK1gKDT86jm/75gqdTmSIJQ5KHejaq1GP43HuC0eb+0aXZ7bj7D/9kT7A3MGWec4mj 2w8Tln9E1FcdpvPYsKmc70ucz7fVoi9Ym6WrbBDlN2geRF4s/NMx60M2ip+ql9jcle6E mMLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=4jIbEBRomxYAKZxpKkf0ZM3dSAusy77ln8vzjtKtO2o=; b=03Ojchi2Vw1JyiPMGlKk15p227CYm8PdVdan/M2zdM2MCTKiu9tkX4OzyHccIyvfH+ 88p2V8o7vpD1JHL+UMFrRfMZnBSyv54kMYnhFDFmgmGH8cBvzvwQdPNRUMhGggm6KZsQ /mE95afYoRRjAymVsFRfy1pw25aeI6e+0SscwkCv4oVMGCav81KcF+BzERtIGg+R36+X rPKESnnBPyGhfiB4P0pM4coMUrmWgj5QDqf2u6MTZjBj7jh8h9Zcfw/H+sl0GULyefd5 qeVZyMgnkzHPJUlELJOY7PK33X5axHWCaXCyTh9KHJ8PfsJbjWo+ZtrZGNSQ4i26YO/r 97NQ== X-Gm-Message-State: AOAM533R38cbArwRKl/fpmJDG+CLBtS1AQP04vRGSfjbq5JgEu54Xwhh ewq7WhaqzKvFpZTsYj36LAHCnY7RPzQ= X-Google-Smtp-Source: ABdhPJylkPF3rcxpuQwJf+qtwse4qPnykwPu73RqlxpI8J+NU4QmSO+UnnR3pbWkoRIXFE2wLYidyw== X-Received: by 2002:aa7:d4c7:0:b0:42b:cf45:1701 with SMTP id t7-20020aa7d4c7000000b0042bcf451701mr8879199edr.161.1653595422959; Thu, 26 May 2022 13:03:42 -0700 (PDT) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id de30-20020a1709069bde00b006f3ef214debsm785250ejc.81.2022.05.26.13.03.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 May 2022 13:03:42 -0700 (PDT) Message-ID: Subject: Re: Breaking change: Make 'description' of mandatory From: Liliana Marie Prikler To: Reily Siegel , guix-devel@gnu.org Date: Thu, 26 May 2022 22:03:41 +0200 In-Reply-To: <87leuospz5.fsf@reilysiegel.com> References: <87leuospz5.fsf@reilysiegel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2a00:1450:4864:20::544; envelope-from=liliana.prikler@gmail.com; helo=mail-ed1-x544.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 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 X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1653595527; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=4jIbEBRomxYAKZxpKkf0ZM3dSAusy77ln8vzjtKtO2o=; b=f+XklGLpf5CANxsQ1NykBen7d7sznK/lpel8M000niYhsdxPIMtfeNl3j/GWYSKSEfIpST j6uQUZVFJDC0uFfZsEFbfqaLcqdOkxgDXPE4P+A0dS+QoEUz2Mnxw1KS3sZfMMk5kNMvNY OKe0zDV28k2z4/gE4LedtRxMFzQEQ/pQfEjLJe1Ryf9+7VnAxRkHow0VCjjtf43V+d2Fv5 530+I2yicHJGUAPkiAg/6gC6SsKXiJqNFY1B22pTo5uLNxYAuE+i//WGivWxcUPU5NF5mo 7Jdhs9i8cu6Nc2ZR1nBzIuo1EaTU5A39SC2zJSu2TOQd51k55v3RAWM1gLcxuA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1653595527; a=rsa-sha256; cv=none; b=QTZLQXgBQ96ktNDLYCeEuz9aOXh+Na4E+SmacF5rpGe1z2RTC63gS6z6Pu5P3bo+0EPJoe h45xqBRiFYEi9rAKpZJRBKvDaDskQX7JkC4I3cfBG+eB7KUX5ImVWigbXbP4k4Tzpoogrt fMriVLkDvlGls3MjRFJR4N6pJng0OXXwCx1IBBDixMeuinAq2joe7RO4XWmho+J2yXMjI2 s/BBePufCenomsXLqyP7DnQvJHY7UNTdlRJqH5tRW5cbN+7evB1fhZReYMT8NlTzYerein IHsQQGe9ZmGKGdK3/2ynrlXMLaCC4KywwB8BN8PoEwpW1QBEJ7k2htptkwmrKw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Jcjzgl2E; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -7.14 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Jcjzgl2E; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 7CE9DE0F9 X-Spam-Score: -7.14 X-Migadu-Scanner: scn0.migadu.com X-TUID: L1URKuyQUReZ Hi, Am Donnerstag, dem 26.05.2022 um 09:38 +0200 schrieb Reily Siegel: > The solution here is incredibly obvious, I just need to add > descriptions to services I declare in my configuration, but that this > change happened, and I didn't see anyone else have issues on guix- > devel, guix-help, or elsewhere (I may have missed something), I > thought it a good idea to ask if I am doing something unsupported in > my configuration. I don't think so. Patches tend to sleep in the mailing list for a while (the documentation says something about 14 days, but patches have been pushed quicker than that). People in a similar situation likely have already noticed and documented their services in advance; even if not, someone always has to be the first to publicly notice. > The problem arises when a certain feature needs to extend two > services to be useful: take configuration of an emacs package. It > must first extend (in the case of Guix home) home-emacs-service (from > RDE channel) with the emacs configuration to be inserted to init.el, > and home-profile-service-type, to add the emacs package to the > profile. > It seems like simple-service /would/ be a good option here, except as > best I can figure out it can only extend one service. So instead, I > create a new service-type, perhaps named my-emacs-feature- > configuration-service, > which takes no value and has no extension mechanism, but only serves > to extend multiple other "real" services. To be fair, that's a pretty weird design for design sake. You could for instance make it s.t. your service takes a list of package+snippet pairs as configuration, adding the package to your profile and the snippet to your init.el. That'd be more generic than a "one-off" definition that only carries your own configuration. > This change (and the discussion at https://issues.guix.gnu.org/55404) > indicates to me that all service-types, no matter where they are > implemented, are meant to be consumed by a generic user, not used in > a one-off way like my configuration does. > > So, to sum up, I have a few questions: > > 1. Is service-type meant for use in individual user configurations? Yes and no. You can freely define new service types if it helps you, but the way you describe seems like a somewhat large hammer. If your service type provides no useful abstraction, why not use simple services instead, even if you have to write multiple ones? > 2. Is there an equivalent function to simple-service that takes > multiple >    service/value pairs that I have missed? >    (e.g., (simple-service-like service-a val-a service-b val-b ...) >     or (simple-service-like (list service-a val-a service-b val-b))) You can group multiple simple-services into a list, i.e.  (define my-service-collection (list (simple-service service-a val-a) (simple-service service-b val-b))) and then add that to your configuration via append. > 3. If the answer to 2 is no, does it make sense to extend > simple-service to work with multiple service extensions, or is > there some reason for only extending one service at a time? No, you're nail-seeking. Just because one way of doing things has vanished doesn't mean that there aren't others that end up with the same result. As an analogy, (template) metaprogramming in C++ is Turing-complete, so you could, for example, write a program that computes a specific instance of 3SAT at compile time and the compiled program will either be puts("yes") or puts("no"), depending on whether the formula was satisfiable or not. While incredibly cool, doing that serves no real purpose – the compiled program does not solve 3SAT, it's essentially hello world. Service types without configuration in a similar manner "do nothing", i.e. they don't offer a way for the user to express their desired system more concisely than if they didn't have them. Once you do have a configuration, you have to think about what parts of your system it abstracts and makes easier to configure, ad so on and so forth, thus naturally leading to some documentation. I wasn't involved in any discussion around this feature, so you might want to take my opinion with a grain of salt; nevertheless I hope it's useful to think about things in that way. Documenting your service types should also be more helpful if you ever want to share them with upstream, though in the particular case of Guix Home that's split in two very distinct realms that might not be as simple as I've just said. Cheers