Hi Konrad,
Konrad Hinsen <konrad.hin...@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’.
