Re: Questions regarding substitutes with debug output

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

On Fri, 29 Apr 2022, zimoun <zimon.toutoune@gmail.com> wrote:
> Hi Olivier,
>
> On Thu, 28 Apr 2022 at 10:11, Olivier Dion via <help-guix@gnu.org> wrote:
>> On Thu, 28 Apr 2022, zimoun <zimon.toutoune@gmail.com> 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 «to
> specify the package programmatically». :-)

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 – 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.
>
> Well, I think you are “overengineering“. :-) I am lacking of imagination
> about a channel containing several packages with the exact same name,
> version, output but applying a variation to ’arguments’ or ’inputs’.

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=1' 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 – 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.
>
>
> Rethinking about the feature request, what I would do:
>
>  1. channel with variants where each variant contains a ’properties’ (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 ’properties’;
>  probably using ’fold-packages’.
>
> Well, #2 means write by hand my own version ’find-best-packages-by-name’.
>
> Maybe the API could have a function returning a list of packages from
> its arguments name, version, output *and* a ’properties’
> 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=#t"

or something similar.

> Well, this mapping could be included as another ’properties’.  When
> building the cache (~/.config/guix/current/lib/package.cache) with
> ’generate-package-cache’, the cache already contains the module name…
>
> --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---
>
> …but then it is not exploited by ’specifications->manifest’ and co,
> IIUC.

Interesting.  I'll look into that.

Regards,
old

-- 
Olivier Dion
oldiob.dev