unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: Olivier Dion <olivier.dion@polymtl.ca>,
	Maxim Cournoyer <maxim.cournoyer@gmail.com>,
	Olivier Dion via <help-guix@gnu.org>,
	Ricardo Wurmus <rekado@elephly.net>
Subject: Re: Questions regarding substitutes with debug output
Date: Fri, 29 Apr 2022 10:49:47 +0200	[thread overview]
Message-ID: <87ee1ge0k4.fsf@gmail.com> (raw)
In-Reply-To: <87mtg5qovg.fsf@laura>

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». :-)


>> 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’.

About ’arguments’, you need a short key as metadata, and the simplest is
to put this key directly in the name or version or output.

About ’inputs’, it remembers me «parameterized package», e.g., see [1].

1: <https://yhetil.org/guix/87eeku8trb.fsf@gnu.org>.


>> 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)

 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.


>> 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.

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.


All in all, maybe it is time to resume: :-)

    https://issues.guix.gnu.org/39258

Cheers,
simon


  parent reply	other threads:[~2022-04-29 11:07 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-20 17:32 Questions regarding substitutes with debug output Olivier Dion via
2022-04-22  4:22 ` Maxim Cournoyer
2022-04-22 14:29   ` Olivier Dion via
2022-04-24  3:38     ` Maxim Cournoyer
2022-04-24 14:56       ` Olivier Dion via
2022-04-25  4:10         ` Maxim Cournoyer
2022-04-28  8:13     ` zimoun
2022-04-28  8:58       ` Ricardo Wurmus
2022-04-28 14:11       ` Olivier Dion via
2022-04-28 14:18         ` Ricardo Wurmus
2022-04-28 14:25           ` Olivier Dion via
2022-04-29  5:06             ` Ricardo Wurmus
2022-04-28 14:20         ` Olivier Dion via
2022-04-29  8:49         ` zimoun [this message]
2022-04-29 14:47           ` Olivier Dion via
2022-04-29 16:01             ` Ricardo Wurmus
2022-04-29 16:17               ` Olivier Dion via
2022-04-29 20:08                 ` Ricardo Wurmus
2022-04-29 20:53                   ` Olivier Dion via
2022-05-09 10:33                   ` zimoun
2022-05-09 13:33                     ` Ricardo Wurmus
2022-05-09 14:37                       ` zimoun
2022-04-29 16:06             ` zimoun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ee1ge0k4.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=help-guix@gnu.org \
    --cc=maxim.cournoyer@gmail.com \
    --cc=olivier.dion@polymtl.ca \
    --cc=rekado@elephly.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).