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 ms5.migadu.com with LMTPS id uJb2I2GkamL9RAEAbAwnHQ (envelope-from ) for ; Thu, 28 Apr 2022 16:27:45 +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 yKDmI2GkamJzFwAA9RJhRA (envelope-from ) for ; Thu, 28 Apr 2022 16:27:45 +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 0CF7130A69 for ; Thu, 28 Apr 2022 16:27:45 +0200 (CEST) Received: from localhost ([::1]:55542 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nk57P-0006jz-MC for larch@yhetil.org; Thu, 28 Apr 2022 10:27:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34264) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nk4sF-0004KP-DT for help-guix@gnu.org; Thu, 28 Apr 2022 10:12:06 -0400 Received: from smtp.polymtl.ca ([132.207.4.11]:44505) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nk4sB-0000nX-Or for help-guix@gnu.org; Thu, 28 Apr 2022 10:12:01 -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 23SEBV7Y004746 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Apr 2022 10:11:35 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 23SEBV7Y004746 To: zimoun , Maxim Cournoyer , Olivier Dion via , Ricardo Wurmus Subject: Re: Questions regarding substitutes with debug output In-Reply-To: <86mtg5eibr.fsf@gmail.com> References: <877d7joe2w.fsf@laura> <87levx4ui1.fsf@gmail.com> <87ee1pur82.fsf@laura> <86mtg5eibr.fsf@gmail.com> Date: Thu, 28 Apr 2022 10:11:31 -0400 Message-ID: <87mtg5qovg.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 Thu, 28 Apr 2022 14:11:31 +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=1651156065; 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=OoyOvOzrx2EbYGOFmQNnbodtIka2hrm1g1vinR85rKg=; b=f4K1hxBo3hGztXjXguGMQJEIV32yn9Xg/jVIkPYhUU7dH1f3ytgAl+SSxbVPeZJg/BX4So W5B7IneK2p5TL2EgFLXK9lSEZuTJAvx5sQrR4Nz6WzTJZamnTxn2vNdLhmLM4IfUiMyK4e NtXDfQ52PR0rQg+ZM7geCbe4xwwWfCOgCGiJicA+B0fU2aFdNQmwIb1wK6P10gDunvzalx Gn8aTbwsLlD9u2cGpIXnDp3LkBbqua4kFom7vGblMocb3FP0hK0BM3iTmJurSx6tdSvozh QTl096cS1wqYg+8tepzODuJY3VFnln49X5z61gX1gT3NpZFv0ehz/06ls1lkTg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1651156065; a=rsa-sha256; cv=none; b=rHdvZSNPpuyUNE4j+K4UYU30NXnLF4j/A1B+2hSOlt5nd8hBIP5qhjJ3QHl5PC3mC3XOsD Iux+0p3bfoeGlMQwPOfIMbt0aPUwaMsVk67C5/Ph8c4HrYEySkNVaMwCYdJTkYS5OvBS0p cnuLYkcT6fxe7OpJ/SGTK7n9o4uej887G+2enc0nzAi6hXOI4kAXj76Tc/dvI/5qU4nKQW QbX7ajPqdRzbMQY8OqREWFkxpsX+cM/ofcf6OcAAmThonkp6KUAmAYZik0CzlgB+keLWIA PB+E2x8+lEOEpRmXVWw7w4cSzOXxO+Kt5ocFIC08DDKDou9N0KFExJd0KfCgIA== 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: -2.10 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: 0CF7130A69 X-Spam-Score: -2.10 X-Migadu-Scanner: scn0.migadu.com X-TUID: RunUmrlRwqhK On Thu, 28 Apr 2022, zimoun wrote: > Hi, > > On Fri, 22 Apr 2022 at 10:29, Olivier Dion via wrote: >> On Fri, 22 Apr 2022, Maxim Cournoyer wrote: > >>> Channels can only extend, not override the default Guix channel (the >>> world would be a bit of a mess if it did). So the easiest path is to >>> use a different name; alternatively for graph rewriting you could use >>> the various APIs to effect package transformations. >> >> Would be nice to have some way to specify channel in a package >> specification. I don't think that it would break things if we >> considerer channels as namespaces, i.e. different graph. A >> specification like: >> >> {channel}package@version:output >> >> would be useful. For now I will just rename them to "my/package". > > What do you mean by =C2=ABdifferent graph=C2=BB? From my understanding, = the > additions of channels makes just the graph bigger: extending the initial > (upstream) graph with more nodes (channel). :-) Right it's not a new graph per say since you're not introducing the full dependencies themself. You're only pulling more nodes into the graph. I guess the correct term would be a "view" of the graph. My point being it would be cool if we can specify a package with a preference if two packages have the same name. It could be the channel name, but it could also be some metadata provided by Guix. So really, one could build a specific query (specification) until only a single package is left from the setfff of matches. Could be something like: "guile@3.0.8:debug;channel=3Dmy-channel;some-metadata=3Dfoo" I don't know, I'm making syntax up. But I think it would be useful in cases outside of mine. I'm thinking about root filesystems for embedded systems where you might want to use a variant of some package. > IIUC, the question is how to refer to these nodes, and from my > understanding, we use basically two ways: > > 1. by symbol; and thanks to Guile modules, this way provides > namespaces, somehow. >=20=20 > 2. by metadata (name, version, output); and here I am not convinced it > is doable to have a namespace but maybe mimic it. > > Therefore, since your question is rooted from GWL: > > I need to specify the package programmatically as a string in > Guile. More specifically in the process packages field of Guix > Workflow Language. > > maybe GWL could also accept a symbol instead of a name string. Well, I > have not used GWL since many months and I do not remember but I think it > is doable. Ricardo? 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. > 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. > Aside the syntax of the string =E2=80=93 why not the one your are proposi= ng =E2=80=93 > and so adapt =E2=80=99package-name->name+version=E2=80=99 (or similar), t= he function > =E2=80=99find-best-packages-by-name=E2=80=99 requires some improvements. > > 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. I could not say. I don't know much about the internal of Guix :-/. > Therefore, assuming this mapping, the package cache > (%package-cache-file) could be updated to also track such map. Such > feature would also simplify when searching; especially for variants > (same as upstream but other arguments). Yes that would be the idea! Regards, old --=20 Olivier Dion oldiob.dev