Le Sat, 31 Oct 2020 18:30:07 +0100, Ludovic Courtès a écrit : > Hi Julien, > > Julien Lepiller skribis: > > > %load-path lists ~/.config/guix/current before individual channels. > > We use canonicalize-path to get the store path for channel > > packages. > > > > * guix/describe.scm (package-provenance): Use canonicalize-path. > > [...] > > > (let ((file (if (string-prefix? "/" file) > > file > > - (search-path %load-path file)))) > > + (canonicalize-path (search-path %load-path > > file))))) > > Could you explain what problem it solves, perhaps with a simple > reproducer? Thanks for the answer! Maybe this is only an issue in guix repl, but when looking for the provenance of a package that's defined in a channel, I always get `#f`: guix repl ,use (guix describe) ,use (gnu packages gettext) ,use (my channel packages) (package-provenance po4a) -> I get the guix channel (package-provenance my-package) -> I get #f To me, this is caused by the search-path returning a path in ~/.config/guix/current instead of /gnu/store as it does for po4a: (search-path %load-path "gnu/packages/gettext.scm") -> /gnu/store... (search-path %load-path "my/channel/packages.scm") -> /home/... The reason why I use canonicalize-path here is because doing so, I get a path in the store, that is the content of the channel, so the procedure can return that channel as the provenance for the package. Unfortunately, %load-path seems to be weirdly set when using pre-inst-env, so I'm not sure how to test (channel modules are not even found). > > ‘search-path’ can return #f (there’s a test right below), so this > should probably be: (and=> (search-path …) canonicalize-path). > > As a rule of thumb, I think twice before calling ‘canonicalize-path’ > because (1) it’s expensive (lots of stat(2) calls), and (2) it can > have undesirable effects on the UI (messages mention a file name > other than the one the user typed) and elsewhere (on logic that looks > at what the file name looks like). I think the result of canonicalize-path is only used internally in that function to find the channel a package comes from, but is never used outside of this function (it's not returned). > > Maybe it’s OK here, but I mention this for completeness. > > Thanks, > Ludo’. Attached is an updated patch.