Re: Finding the store path of a package

[Konrad Hinsen <konrad.hinsen@fastmail.net>]

[-- Attachment #1: Type: text/plain, Size: 3012 bytes --]

Hi Ludo,

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

Four weeks later: this mostly works, but sometimes fails (by
downloading/building package) and it rarely fails completely
(error message). And I have no idea what is going on.

As an experiment, I ran the attached script via "guix repl". It requests
and displays the store paths for all non-hidden packages. Using
"guix gc" before and after, I found that it downloads/builds
more than 50000 store entries with a total size of 7.5 GB.

One small but interesting example: ABCL

##################################################
Store paths for abcl@1.8.0:
fetching path `/gnu/store/rz42ba0my9vrgbkjpkzr2drmnjk5ah50-python-3.8.2'...
Downloading https://ci.guix.gnu.org/nar/lzip/rz42ba0my9vrgbkjpkzr2drmnjk5ah50-python-3.8.2...
 python-3.8.2  12.0MiB                1.8MiB/s 00:07 [##################] 100.0%

fetching path `/gnu/store/bvd09gb8ka642jzgxd2lpqlpdp160gn0-python-wrapper-3.8.2'...
Downloading https://ci.guix.gnu.org/nar/lzip/bvd09gb8ka642jzgxd2lpqlpdp160gn0-python-wrapper-3.8.2...
 python-wrapper-3.8.2  347B           177KiB/s 00:00 [##################] 100.0%

fetching path `/gnu/store/h8z924ip7ialjhd3sc2id5yh0jy7cj20-python-nose-1.3.7'...
Downloading https://ci.guix.gnu.org/nar/lzip/h8z924ip7ialjhd3sc2id5yh0jy7cj20-python-nose-1.3.7...
 python-nose-1.3.7  197KiB            1.4MiB/s 00:00 [##################] 100.0%

fetching path `/gnu/store/cshy0265w5ifh12v9dcmlrdd3cwb61db-mercurial-5.6.1'...
Downloading https://ci.guix.gnu.org/nar/lzip/cshy0265w5ifh12v9dcmlrdd3cwb61db-mercurial-5.6.1...
 mercurial-5.6.1  3.3MiB              3.1MiB/s 00:01 [##################] 100.0%

((out . "/gnu/store/nz8xi3x7n3v2k4s4piiw7r8plvxam9qz-abcl-1.8.0"))
##################################################

Why does computing the store path for a Java package require fetching
Mercurial (and thus Python)? The only link I see is icedtea-6, whose
build procedure apparently uses Mercurial to download the OpenJDK
sources. Probably this gets inherited by icedtea-8, which is used for
building ABCL. But... why does it take Mercurial to just compute the
store path??? If my understanding of Guix hashes is correct (which I am
beginning to doubt), it shouldn't require more than the hash of the
Mercurial package.

As an example for a hard failure, see sunxi-tools@1.4.2. Asking for
its store paths downloads plenty of stuff, before failing with:

  while setting up the build environment: a `armhf-linux' is required to build `/gnu/store/4blcfrrzc3yx6xjvw31mhnr1r9lpw4mj-Python-3.8.2.tar.xz.drv', but I am a `x86_64-linux'

That makes sense, of course, and I don't mind getting an error in such a
case, but I'd prefer it to fail without first downloading tons of stuff,
including the heavyweight gcc-7.5.0.

Cheers,
  Konrad.


[-- Attachment #2: display-store-paths.scm --]
[-- Type: application/octet-stream, Size: 888 bytes --]

(use-modules
 (gnu packages)
 (guix packages)
 (guix derivations)
 (guix store))

(define (display-store-paths specification)
  (format (current-error-port)
          "Store paths for ~a:\n" specification)
  (let*
      ((package (specification->package specification))
       (drv (with-store store
                        (package-derivation store package #:graft? #f)))
       (paths (derivation->output-paths drv))
       (store-paths (map (lambda (entry)
                           (cons (string->symbol (car entry)) (cdr entry)))
                         paths)))
    (format (current-error-port)
            "~s\n" store-paths)))

(fold-available-packages
 (lambda* (name version result
		#:key outputs location
		supported? deprecated?
		#:allow-other-keys)
   (if (and supported? (not deprecated?))
       (display-store-paths (format #f "~a@~a" name version))
       #f))
 '())