From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id EJnUGGWR9WDHdQAAgWs5BA (envelope-from ) for ; Mon, 19 Jul 2021 16:51:17 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id kH1+FGWR9WBrEgAA1q6Kng (envelope-from ) for ; Mon, 19 Jul 2021 14:51:17 +0000 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 A393316EDC for ; Mon, 19 Jul 2021 16:51:16 +0200 (CEST) Received: from localhost ([::1]:33232 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m5Ubz-00021J-L6 for larch@yhetil.org; Mon, 19 Jul 2021 10:51:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37646) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m5Ubm-000203-C4 for guix-patches@gnu.org; Mon, 19 Jul 2021 10:51:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:48187) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m5Ubm-0007w6-2Z for guix-patches@gnu.org; Mon, 19 Jul 2021 10:51:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1m5Ubl-0005tk-Ui for guix-patches@gnu.org; Mon, 19 Jul 2021 10:51:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#49597] [PATCH core-updates 00/15] Ajust packages to label-less input style Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Mon, 19 Jul 2021 14:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49597 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Maxime Devos Cc: 49597@debbugs.gnu.org Received: via spool by 49597-submit@debbugs.gnu.org id=B49597.162670625422658 (code B ref 49597); Mon, 19 Jul 2021 14:51:01 +0000 Received: (at 49597) by debbugs.gnu.org; 19 Jul 2021 14:50:54 +0000 Received: from localhost ([127.0.0.1]:59733 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m5Ubd-0005tO-Ta for submit@debbugs.gnu.org; Mon, 19 Jul 2021 10:50:54 -0400 Received: from eggs.gnu.org ([209.51.188.92]:39838) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m5Ubb-0005tB-Je for 49597@debbugs.gnu.org; Mon, 19 Jul 2021 10:50:52 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44320) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m5UbT-0007e4-Uj; Mon, 19 Jul 2021 10:50:44 -0400 Received: from [2001:660:6102:320:e120:2c8f:8909:cdfe] (port=42874 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m5UbT-00011F-Me; Mon, 19 Jul 2021 10:50:43 -0400 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <20210716155009.32118-1-ludo@gnu.org> Date: Mon, 19 Jul 2021 16:50:40 +0200 In-Reply-To: (Maxime Devos's message of "Sun, 18 Jul 2021 17:44:01 +0200") Message-ID: <87tukqmk73.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-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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1626706277; 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=5mSLeAP+tSsdiJF47jN59tpB8f7kodz0h+5HOL9l1oA=; b=VN0qG7kyG2pgjVzZlDc/ejz66vXqVX/5CDUqgm9r6/kiZIH5abc4MUkbiSX9N1hHJiUhFO uybLP6OURNODsMAlQUc/6y/8sYve0/xq6JQKQiURHDDc4RZxabYovVCm3StAm01Q1eGOit 0OOaOlk2OjE80lo3pT5+UboocG0XPMXlF7C0zDajLmv9/azza3leTWYqHyNGWbn68ez6yZ nQ1bRg7POzuOLhaHm4FfYzWFjWR5SpD/uBA2z2nmsBKdi1Wc4B7nQ0rGT+B3KU22h7zb9V heVfwCyIVGmdVkpcmxxO/41So8G2ZAZxJn6Zrlrj8sxYxd30ruRpPolRbMiMHg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1626706277; a=rsa-sha256; cv=none; b=EHoGOg3SdO0v2g5j4Gf6+q0MHjlkbdzamgk+ZLHEjUFp9CnNZRQ+AoiU3U5WI8z2VvpMSy EgveLRPwc502pTIS0VTcmQVVSIQSEQJaZfGSGBSao+kAxSXazcYt7ttt7NSzGJsPsItFVb aoY7jZHbVa45ZOsZdvnnytp2OVlMCt+zw9zviUwQj37qQjpV9pdF0qbQPtGLkEetCi3dLR /HIDdC5CB8WeEJHfSrcxIqi3c48nfmwyEzrGNaFFkVvgUZOnSa9vydqo9tL6haovqCLg6Y l3clowsYOnEw0Z50Xp+6wvyp9CT5/jGeBetcEpIW8mLguxu3JyjAYO3h+Ji5Nw== 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@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Spam-Score: -2.91 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@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Queue-Id: A393316EDC X-Spam-Score: -2.91 X-Migadu-Scanner: scn0.migadu.com X-TUID: V8iGk3XLNXQM Hello Maxime! Maxime Devos skribis: > Ludovic Court=C3=A8s schreef op vr 16-07-2021 om 17:50 [+0200]: >> The rest is about removing reliance on input labels in build-side >> code, primarily by changing: >>=20 >> (string-append (assoc-ref inputs "LABEL") "FILE") >>=20 >> to one of: >>=20 >> (search-input-file inputs "FILE") >> (search-input-directory inputs "FILE") >>=20 >> This change will help if we eventually remove input labels entirely >> from the API (remember that input labels are now unnecessary in >> package definitions but they=E2=80=99re still returned by =E2=80=98packa= ge-inputs=E2=80=99 >> and similar procedures). >>=20 >> The idea is that code should not rely on package names when looking >> for files as this would prevent things such as >> =E2=80=98--with-inputs=3Dopenmpi=3Dmpich=E2=80=99 since the label in the= original package >> would be =E2=80=9Copenmpi=E2=80=9D whereas it=E2=80=99d be =E2=80=9Cmpic= h=E2=80=9D in the transformed package. >> In this case (a kind of =E2=80=9Cvirtual dependencies=E2=80=9D), a bette= r idiom is: >>=20 >> (search-input-file inputs "lib/libmpi.so") >>=20 >> as this explicitly accommodates any implementation of that library. > > I would have expected that --with-inputs=3Dx=3Dy would turn the following: > > (package > [...] > (inputs `(("x" ,x)))) > > into: > > (package > [...] > (inputs `(("x" ,y)))) > > i.e., keep the label intact, but change the package value. Yes, that=E2=80=99s what happens right now, even on =E2=80=98core-updates= =E2=80=99. So to be clear, there=E2=80=99s no problem at this point. There will be a problem when we remove input labels entirely from the API. At that point, the labels that build-side code will see (if we keep them at all=E2=80=A6) will necessarily be package names. In the examp= le above, =E2=80=9Cx=E2=80=9D would be replaced by =E2=80=9Cy=E2=80=9D. This series is one way to anticipate for this change (which would happen at the earliest on the next =E2=80=98core-updates=E2=80=99 cycle, which cou= ld be six months from now, maybe more). [...] > In the example you gave, both search-input-file and the original 'string-= append' > and 'assoc-ref' look convenient to me, though the latter more so than the= other, > and a third variant could be > > #$(file-append (this-package-native-input "openmpi") "/lib/libmpi.so") > > which avoids 'string-append' and 'assoc-ref'. Yes, but you=E2=80=99re still relying on the name, =E2=80=9Copenmpi=E2=80= =9D. If I do: (package (inherit thing) (inputs `(("mpich" ,mpich) ,@(delete "openmpi" (package-inputs thing))))) =E2=80=A6 then you have a problem: =E2=80=98this-package-input=E2=80=99 won= =E2=80=99t find =E2=80=9Copenmpi=E2=80=9D. It=E2=80=99s a real, common use case. That=E2=80=99s why we need to be car= eful about the idioms we promote. WDYT? > (I prefer explicitely writing in the package definition in which input a = file > will be found, as a kind of documentation, though in this case it probably > doesn't really matter.) Yeah, I like that too. OTOH, =E2=80=98search-input-file=E2=80=99 has the a= dvantage that it errors out if the file is not found, whereas (string-append (assoc-ref inputs "foo") "bar") always =E2=80=9Cworks=E2=80=9D and problems occur possibly much later, at r= un time. > An idea behind this series of patch series seems to be to eliminate > input labels entirely. Is that true / false? This is true: it=E2=80=99s a step to make it possible to eventually remove = input labels entirely. > A benefit of having procedures like 'modify-inputs' instead of having > random code assume package inputs are alists with a certain structure, > is that this opens some opportunities to experiment with the nature > of inputs. Exactly. > More specifically, take 'propagated-inputs'. Guile dependencies of > guile libraries usually have to be added to 'propagated-inputs', > even if the library package can also be used as a program. If the > user only wants to use it as a program, then the propagation isn't > necessary. So introducing some kind of 'context-dependent propagation' > might be interesting, to reduce propagation conflicts. Ah ha! That=E2=80=99s a different can of worms though. :-) Thanks, Ludo=E2=80=99.