[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Finding the store path of a package

From: Ludovic Courtès
Subject: Re: Finding the store path of a package
Date: Mon, 22 Mar 2021 17:22:03 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Hi Konrad,

Konrad Hinsen <> 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/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:


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]