Re: Questions regarding substitutes with debug output

[Olivier Dion via <help-guix@gnu.org>]

On Thu, 28 Apr 2022, zimoun <zimon.toutoune@gmail.com> wrote:
> Hi,
>
> On Fri, 22 Apr 2022 at 10:29, Olivier Dion via <help-guix@gnu.org> wrote:
>> On Fri, 22 Apr 2022, Maxim Cournoyer <maxim.cournoyer@gmail.com> 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 «different graph»?  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=my-channel;some-metadata=foo"

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.
>  
>  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 – 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
> <channel>, 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 – why not the one your are proposing –
> and so adapt ’package-name->name+version’ (or similar), the function
> ’find-best-packages-by-name’ 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

-- 
Olivier Dion
oldiob.dev