Re: Finding the store path of a package

["Ludovic Courtès" <ludo@gnu.org>]

Hi Konrad,

Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:

>> Yes.  In the presence of grafts, run “guix build PKG”.  That always
>> gives you the store file name of PKG, 100% reliable!
>
> At the cost of a few hours of CPU time, in the worst case.
>
>> I regularly do things like:
>>
>>   ls $(guix build PKG)/bin
>>   find $(guix build PKG) -name …
>
> What I am looking for is the equivalent of
>
>    ls $(guix build PKG)
>
> that fails in whatever way for packages that are not in the store, but
> guarantees (1) not adding anything to the store and (2) response times
> short enough for interactive user interfaces.
>
>> If you want a variant that does that without building/downloading it,
>> it’s also possible, though not as easily from the command line.
>
> Guile is fine, no problem. But so far, I haven't found anything even at
> the Guile level that respects my two conditions.

Here’s an example of how to do that:

--8<---------------cut here---------------start------------->8---
scheme@(guix-user)> ,use(guix)
scheme@(guix-user)> (define s (open-connection ))
scheme@(guix-user)> ,use(gnu packages base)
scheme@(guix-user)> (package-derivation s coreutils #:graft? #f)
$1 = #<derivation /gnu/store/k0h3zahr74ky7z4hy5nklk5ar1b841nc-coreutils-8.32.drv => /gnu/store/yvsd53rkbvy9q8ak6681hai62nm6rf31-coreutils-8.32-debug /gnu/store/n8awazyldv9hbzb7pjcw76hiifmvrpvd-coreutils-8.32 7fc814f2e1e0>
scheme@(guix-user)> (derivation-outputs $1)
$2 = (("debug" . #<<derivation-output> path: "/gnu/store/yvsd53rkbvy9q8ak6681hai62nm6rf31-coreutils-8.32-debug" hash-algo: #f hash: #f recursive?: #f>) ("out" . #<<derivation-output> path: "/gnu/store/n8awazyldv9hbzb7pjcw76hiifmvrpvd-coreutils-8.32" hash-algo: #f hash: #f recursive?: #f>))
scheme@(guix-user)> (derivation->output-path $1 "out")
$3 = "/gnu/store/n8awazyldv9hbzb7pjcw76hiifmvrpvd-coreutils-8.32"
--8<---------------cut here---------------end--------------->8---

Why #:graft? #f?  Because if you enable graft, you’ll potentially have
to build/download the thing, and that wouldn’t buy you anything because
the set of file names is the same in the grafted package.

Does that make sense?

> Background: I am working on a interactive UI for running reproducible
> computations via Guix:
>
>   https://github.com/khinsen/guix-gtoolkit/

Nice!

> I'd like to implement (1) browsing package contents ("what exactly do I
> get by adding "core-utils" to my environment?") and (2) searching
> packages by the files they contain ("which package do I have to add to
> my environment to get the ls command?"). There will be a button for
> explicitly building a package, but I don't want it to happen as a side
> effect when doing operations that need to be fast.

For #2, there have been discussions about building a service that would
create such a database—a mapping from file names to packages.  It’s not
possible to do with purely local knowledge because, by definition, you’d
have to build/download every package.  I don’t think it has materialized
yet, though.

Thanks,
Ludo’.