From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id AOU7FkA992DljQAAgWs5BA (envelope-from ) for ; Tue, 20 Jul 2021 23:16:48 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id 8J/bEUA992BBEAAAbx9fmQ (envelope-from ) for ; Tue, 20 Jul 2021 21:16:48 +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 907DB123B9 for ; Tue, 20 Jul 2021 23:16:47 +0200 (CEST) Received: from localhost ([::1]:43766 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m5x6c-0001dR-FB for larch@yhetil.org; Tue, 20 Jul 2021 17:16:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46362) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m5x4w-0007ZF-MH for guix-patches@gnu.org; Tue, 20 Jul 2021 17:15:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:52221) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m5x4w-0001yR-EI for guix-patches@gnu.org; Tue, 20 Jul 2021 17:15:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1m5x4w-00037A-3e for guix-patches@gnu.org; Tue, 20 Jul 2021 17:15:02 -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: Tue, 20 Jul 2021 21:15:02 +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.162681570011951 (code B ref 49597); Tue, 20 Jul 2021 21:15:02 +0000 Received: (at 49597) by debbugs.gnu.org; 20 Jul 2021 21:15:00 +0000 Received: from localhost ([127.0.0.1]:35534 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m5x4t-00036h-HZ for submit@debbugs.gnu.org; Tue, 20 Jul 2021 17:14:59 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48510) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m5x4s-00036Q-Db for 49597@debbugs.gnu.org; Tue, 20 Jul 2021 17:14:58 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58986) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m5x4m-0001rj-JR; Tue, 20 Jul 2021 17:14:52 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=45240 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m5x4m-0000k7-B7; Tue, 20 Jul 2021 17:14:52 -0400 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <20210716155009.32118-1-ludo@gnu.org> <87tukqmk73.fsf_-_@gnu.org> Date: Tue, 20 Jul 2021 23:14:50 +0200 In-Reply-To: (Maxime Devos's message of "Mon, 19 Jul 2021 18:47:54 +0200") Message-ID: <87wnpkit6d.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=1626815808; 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=SZTco954XS6vLRr4E7SQ7qLdrzzoqG5j/OXcv6AZFkc=; b=DlLUceY20oqGC97yS9LxClNdrvQv32hTnS9y4bK5XrjXXG5Si3kEdCE/7NBJPOprCeQVtY o4sGx/c4IwQaVKxE2Vryv+1kIAxs5K2t9haREdxhYERJGHsahEkn+GuEcGSfxuwD+wrO4t AI0v/XWLZVW574WrDq2xlAfEWdQwSjK6M4satc8tNnqRTQXhMlWwYVGLLOIXgJWrz1xmhs 4aYMLAyGRWmGOQDtGIwhPpf6G30Z2OFaTblonblYwSB6OtCQHI56JCQrH432YXCUOPf7cG 4o2X3/ChyxCGuRj12vWb9B9PB9yym35aZdaH/LQFx4exElQ4ReQfIlFzTM5uqw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1626815808; a=rsa-sha256; cv=none; b=fJy7xlR9VFc6oDFhjf/I1ud0qhDKiw4aDg2YM746eupht5Xf/kuv4tZONQ4upuCKmX5xC4 aIwrIzXCdfF+A5CXDm6w/NVOc4xeapsPoRVc06MLUnWwA6nDsYBhBjUYlV7YJb/6+TLfPp ZeFeV/WnLZaqbM/kml6oVGnTAUYE+4OqBrTT8Aq3AfmC3AllOZiNk1QFkGItM2+tmuks2A +lMkXuzjfWBvPjZn76/7iIshxXyqAxEzYvHjIabrR3bwkifRlLssXEHoc38FmSXGKYJUcB dTj3xNhUcb0hxlSdsUsiXNPHPqHj7Klr6z+zoY2VlsVHoqirQt90HYcdJz5fNQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; 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.92 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: 907DB123B9 X-Spam-Score: -2.92 X-Migadu-Scanner: scn1.migadu.com X-TUID: UvbJN1cbfQ7N Hi, Maxime Devos skribis: > Ludovic Court=C3=A8s schreef op ma 19-07-2021 om 16:50 [+0200]: >> [...] >>=20 >> > In the example you gave, both search-input-file and the original 'stri= ng-append' >> > and 'assoc-ref' look convenient to me, though the latter more so than = the other, >> > and a third variant could be >> >=20 >> > #$(file-append (this-package-native-input "openmpi") "/lib/libmpi.so= ") >> >=20 >> > which avoids 'string-append' and 'assoc-ref'. >>=20 >> Yes, but you=E2=80=99re still relying on the name, =E2=80=9Copenmpi=E2= =80=9D. >>=20 >> If I do: >>=20 >> (package >> (inherit thing) >> (inputs `(("mpich" ,mpich) >> ,@(delete "openmpi" (package-inputs thing))))) >>=20 >> =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 = careful about >> the idioms we promote. >>=20 >> WDYT? > > Then you could do: > > (package > (inherit thing) > (inputs `(("openmpi" ,mpich) ; use "openmpi" label > ,@(delete "openmpi" (package-inputs thing))))) > > or just use "mpi" in the original and new package as input label, > but that doesn't mesh well with eventually removing input labels. Yes, but the goal is to remove input labels. :-) > Myself, I don't mind input labels much. They look like arguments to > a procedure to me, albeit with an unusual syntax for referring to > them. Well, we can deal with labels, but removing them lowers the barrier to entry and reduces boilerplate, which most of us enjoy. >> > (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 prob= ably >> > doesn't really matter.) >>=20 >> Yeah, I like that too. OTOH, =E2=80=98search-input-file=E2=80=99 has th= e advantage that >> it errors out if the file is not found, whereas >>=20 >> (string-append (assoc-ref inputs "foo") "bar") >>=20 >> always =E2=80=9Cworks=E2=80=9D and problems occur possibly much later, a= t run time. > > I'd suggest using #+/#$(file-append (this-package-[native]-input "foo") "= /bar" > instead of (string-append (assoc-ref ...) ...). That=E2=80=99s what I had in mind initially, but that means you=E2=80=99re = still relying on labels or package names=C2=B9. Sometimes that=E2=80=99s OK, sometimes n= ot. > I think I have a method for explicitely choosing which input to use, > using package names instead of labels, that still works nicely with > "--with-input": > > (define* (lookup-libmpi-library package) > ;; open-coding could be avoided by adding a 'is-mpi-library?' > ;; package property and using that instead of hard-coding a list > ;; of package names=20 > (file-append (or (lookup-package-input package "openmpi") > (lookup-package-input package "mpich") > ...) > "/lib/libmpi.so")) Yes, an =E2=80=98mpi-library?=E2=80=99 property could do the job, together = with a variant of =E2=80=98lookup-package-input=E2=80=99 that accepts a predicate = rather than a name. Yet, that would only work for cases that packagers have explicitly prepared. For example, the example above won=E2=80=99t work with: --with-input=3Demacs=3Demacs-next unless you actually to the same kind of enumeration or property. This approach just doesn=E2=80=99t scale. But look, in the majority of cases, we don=E2=80=99t do (assoc-ref inputs = =E2=80=A6) at all; we just use things that happen to be in $PATH, $PYTHONPATH, and so on. In a sense, this whole =E2=80=98search-input-file=E2=80=99 strategy follows= that approach. =E2=80=98search-input-file=E2=80=99 is just a generalized versio= n of =E2=80=98which=E2=80=99, as you know. WDYT? Ludo=E2=80=99. =C2=B9 Nix doesn=E2=80=99t have this particular problem: =E2=80=9Cpackages= =E2=80=9D are actually functions, so one can refer to their inputs by value, as in: { stdenv, openmpi, =E2=80=A6 }: { # <- formal parameters of the fun= ction configureFlags =3D [ "--with-mpi=3D${openmpi}" ]; # =E2=80=A6 } I thought about using advanced macrology so that, say, =E2=80=98openmpi= =E2=80=99 is the lexical scope of =E2=80=98arguments=E2=80=99 would be bound to the sa= me =E2=80=98openmpi=E2=80=99 referred to in =E2=80=98inputs=E2=80=99, such that you could write: (package ;; =E2=80=A6 (arguments (list #:configure-flags #~(list (string-append "--with-mpi=3D" #$openmpi)))) (inputs (list openmpi))) I couldn=E2=80=99t think of a reliable way to do that, though. I also think it=E2=80=99s a good idea, performance-wise, to move as much = as possible from the host side to the build side for packages.