Hi, For instance,
--8<---------------cut here---------------start------------->8--- $ guix build -S -d hg-commitsigs substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% 3,7 MB will be downloaded: /gnu/store/6fya762sz5hjdj04vdn5g3v6zii6f11d-mercurial-6.2.2 substituting /gnu/store/6fya762sz5hjdj04vdn5g3v6zii6f11d-mercurial-6.2.2... downloading from https://ci.guix.gnu.org/nar/lzip/6fya762sz5hjdj04vdn5g3v6zii6f11d-mercurial-6.2.2 ... mercurial-6.2.2 3.5MiB 529KiB/s 00:07 ▕██████████████████▏ 100.0% /gnu/store/pkb6zd9xfmxx6rsh4p7w3glh7xqg5sqy-hg-commitsigs-0.1.0-0.b53eb68-checkout.drv --8<---------------cut here---------------end--------------->8--- and it is unexpected. The construction of the fixed-output derivation does not need to download stuff; it only needs to compose stuff detailing how to do. Any download (or build) must happen when running the derivation itself. The issue: later – say 1 or 2 years from now – the command: guix time-machone --commit=929ddec -- build -S -d hg-commitsigs will start to build all what Mercurial needs (python etc.). If for some reasons*, only one of Mercurial dependencies fails then we are doomed. ( Context: I am working on a fixed-output translator; rely on current strategies for downloading and do not require all the past stack just for downloading source code. ) I think it comes from this part: --8<---------------cut here---------------start------------->8--- (hg-fetch '#$(hg-reference-url ref) '#$(hg-reference-changeset ref) #$output #:hg-command (string-append #+hg "/bin/hg"))) --8<---------------cut here---------------end--------------->8--- from ’hg-fetch’ in (guix hg-download). Here the #+hg is not required because just before there is: (set-path-environment-variable "PATH" '("bin") (match '#+inputs (((names dirs outputs ...) ...) dirs))) So relying on string "hg" should be enough; as it is done in ’git-fetch/in-band*’ for one example. Do I miss something? Cheers, simon *reasons of failures: See https://guix.gnu.org/en/blog/2024/adventures-on-the-quest-for-long-term-reproducible-deployment