From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.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 cH4sHCv+a2LLHAEAbAwnHQ (envelope-from ) for ; Fri, 29 Apr 2022 17:03:07 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id cLLQGyv+a2LdXQAA9RJhRA (envelope-from ) for ; Fri, 29 Apr 2022 17:03:07 +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 E0EF4284E2 for ; Fri, 29 Apr 2022 17:03:06 +0200 (CEST) Received: from localhost ([::1]:44318 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nkS9B-0004PV-Ka for larch@yhetil.org; Fri, 29 Apr 2022 11:03:05 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36524) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkRuU-0002CO-Id for help-guix@gnu.org; Fri, 29 Apr 2022 10:47:54 -0400 Received: from smtp.polymtl.ca ([132.207.4.11]:56836) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkRuR-0000mE-ME for help-guix@gnu.org; Fri, 29 Apr 2022 10:47:53 -0400 Received: from localhost (modemcable094.169-200-24.mc.videotron.ca [24.200.169.94]) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 23TElZrM031390 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 29 Apr 2022 10:47:40 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 23TElZrM031390 To: zimoun , Maxim Cournoyer , Olivier Dion via , Ricardo Wurmus Subject: Re: Questions regarding substitutes with debug output In-Reply-To: <87ee1ge0k4.fsf@gmail.com> References: <877d7joe2w.fsf@laura> <87levx4ui1.fsf@gmail.com> <87ee1pur82.fsf@laura> <86mtg5eibr.fsf@gmail.com> <87mtg5qovg.fsf@laura> <87ee1ge0k4.fsf@gmail.com> Date: Fri, 29 Apr 2022 10:47:35 -0400 Message-ID: <87bkwkq73s.fsf@laura> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Poly-FromMTA: (modemcable094.169-200-24.mc.videotron.ca [24.200.169.94]) at Fri, 29 Apr 2022 14:47:35 +0000 Received-SPF: pass client-ip=132.207.4.11; envelope-from=olivier.dion@polymtl.ca; helo=smtp.polymtl.ca X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-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: help-guix@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+larch=yhetil.org@gnu.org Sender: "Help-Guix" Reply-to: Olivier Dion From: Olivier Dion via 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=1651244587; h=from:from:sender:sender:reply-to: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; bh=bFcXaBzi41ozEz/8dJglwC/BsRSB8cMcRgdV5Sl/OFs=; b=ELY7FCk962OiQxt7ilTf8F8CgzMsZfGY9pHd66VSz3rg69iJRrbcQr+L1/R6RRbSNcz67V PM/XDg5h6JthB5ePDq3ovevYKWqthv+izdEoNrpYiP+oQQ9lIL9NOSE23s4XYDVqo6J5P5 LPUi3HK0MQQTWMYIYp457FhukPc/evCA6Y77lbFBi4vR4qGlp450Bad4o+aycUFvtL+oAG S6PKB6YWJQaExVJ4VihcglO2G5I+ESLYqg4oQvKH7VNSSRFMblUJGqcVKvBO3qs+St3Aki L5crvFMElh+p8R6LJXO2vCmxTEw7FzZs9kMHX8Z9XXgFAWCvAFYU0DASHJ8kgA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1651244587; a=rsa-sha256; cv=none; b=gwBDJ/8MXj7alsYqQlaY+0/ReWC9wXi5MG0pLJZ2Lyx9C1q02wW1kKGjDpcREYLZ5daU/E cJFyc986bYOSxpiZBjVtUln9nqh3ZyVKjo2lwq5nELapQpxhuCMASpcHToPjZfz9UErL7t v81YJjV/d7zLicr7fcIny+PPb1JBQT3tBssiXcL5dNsC8UNxZdKFbuTHK+ZJmPBpim7OGK r++xpjp4+Tkhdb9Og00+dKwHB/DSNp1f0DeZJhr4z74ymb8CZtYmXnYObQsi+meNxDTRbf CA7E+LssOnPnT/HNWdPG63zNDrruXOYfZEZPnyvZqNvOM21JsWI8bmQDvdnEmg== 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 "help-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="help-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -1.50 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "help-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="help-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: E0EF4284E2 X-Spam-Score: -1.50 X-Migadu-Scanner: scn1.migadu.com X-TUID: fejBQ9eOs/I3 On Fri, 29 Apr 2022, zimoun wrote: > Hi Olivier, > > On Thu, 28 Apr 2022 at 10:11, Olivier Dion via wrote: >> On Thu, 28 Apr 2022, zimoun wrote: > >> In my case, I prefer to avoid using package object directly. As >> mentioned in GWL' manual, the version of Guix running GWL and the >> version of Guix used by GWL (the inferior) might not be the same. Thus, >> it is not okay for reproducibility in the long term. In my case, I use >> `guix time-machine --channels` as the inferior. > > You wrote: > > I need to specify the package programmatically as a string in > Guile. More specifically in the process packages field of Guix > Workflow Language. > > so I do not understand why it would be an issue to deal with the package > instead of the specification string. Because your need seems =C2=ABto > specify the package programmatically=C2=BB. :-) Because importing the package using use-modules would yield the package from the instance of Guix driving the workflow instead of using the package of the inferior! GWL will lookup for package in the inferior context when the package is a specification. Even if I were to import locally defined packages, their dependencies would come from the Guix's main channel! >>> Last, back to the feature you would like =E2=80=93 be able to write: >>> >>> (specifications->manifest (list "foo")) >>> >>> and select "foo" from your channel instead from upstream, right? Or a >>> way to specify the channel using the symbol from the name field in >>> , right? >> >> Correct. In fact as I mentioned above, I think having a way to select a >> package variant -- e.g. if you've introduced an existing package in your >> channel -- is a more generic way of describing it. Selection of channel >> being only a type of metadata that can be used for selection of the >> variant. More metadata could be added in the future as well. > > Well, I think you are =E2=80=9Coverengineering=E2=80=9C. :-) I am lacking= of imagination > about a channel containing several packages with the exact same name, > version, output but applying a variation to =E2=80=99arguments=E2=80=99 o= r =E2=80=99inputs=E2=80=99. I have this idea because I've worked on Elbe in the past. It's a root filesystem generator for embedded system based on Debian. Some users of Elbe have different constraints on what can be installed depending on the license, memory footprint, etc. So being able to cherry-pick packages based on some properties is an useful feature here. Of course, you could just define packages locally and ask Guix so use them as long as they have unique name. So you would prefix all of your packages with something like "my/". So now imagine you have a specification -- or something like a DSL -- for describing your full RFS. You generate it and see that its total size is too much for your SD card using default packages. But you have a channel with different variants of some packages. You then apply a preference filter like 'diet=3D1' instead of changing the specification or the module imports. And now you see that your RFS fits in your SD card. But yes, I would also describe it to be over-engineered if the intent is to only have channel preference when there's name collision. But then again, we never know what are the future use case of Guix. >>> Aside the syntax of the string =E2=80=93 why not the one your are propo= sing =E2=80=93 >>> and so adapt =E2=80=99package-name->name+version=E2=80=99 (or similar),= the function >>> =E2=80=99find-best-packages-by-name=E2=80=99 requires some improvements. > > > Rethinking about the feature request, what I would do: > > 1. channel with variants where each variant contains a =E2=80=99properti= es=E2=80=99 (it > is an association list describing whatever you want and kept as-is) Yes so something along: (package ... (properties '((foo . bar) (buz . fuz)))) > 2. write a manifest.scm where I would filter by name and =E2=80=99proper= ties=E2=80=99; > probably using =E2=80=99fold-packages=E2=80=99. > > Well, #2 means write by hand my own version =E2=80=99find-best-packages-b= y-name=E2=80=99. > > Maybe the API could have a function returning a list of packages from > its arguments name, version, output *and* a =E2=80=99properties=E2=80=99 > specification. I concur. >>> What I am missing is the mapping from channel name to package. Well, >>> Guix does not track this information at pull time. And I miss how to >>> implement such mapping. Really this feature is almost not necessary with package's properties: (package ... (properties '((channel . "my-project")))) of course this could be confusing because the actual channel and the properties named 'channel' could have different name. So I would instead do (package ... (properties '((from-my-project? . #t)))) and then "guile;from-my-project=3D#t" or something similar. > Well, this mapping could be included as another =E2=80=99properties=E2=80= =99. When > building the cache (~/.config/guix/current/lib/package.cache) with > =E2=80=99generate-package-cache=E2=80=99, the cache already contains the = module name=E2=80=A6 > > --8<---------------cut here---------------start------------->8--- > (define expand-cache > (match-lambda* > (((module symbol variable) (result . seen)) > (let ((package (variable-ref variable))) > (if (or (vhash-assq package seen) > (hidden-package? package)) > (cons result seen) > (cons (cons `#(,(package-name package) > ,(package-version package) > ,(module-name module) > ,symbol > ,(package-outputs package) > ,(->bool (supported-package? package)) > ,(->bool (package-superseded package)) > ,@(let ((loc (package-location package))) > (if loc > `(,(location-file loc) > ,(location-line loc) > ,(location-column loc)) > '(#f #f #f)))) > result) > (vhash-consq package #t seen))))))) > --8<---------------cut here---------------end--------------->8--- > > =E2=80=A6but then it is not exploited by =E2=80=99specifications->manifes= t=E2=80=99 and co, > IIUC. Interesting. I'll look into that. Regards, old --=20 Olivier Dion oldiob.dev