From 16c5b797a92973091cd2c4ffb30e2067b6e3703d Mon Sep 17 00:00:00 2001
From: K900 <me@0upti.me>
Date: Wed, 2 Apr 2025 09:22:39 +0300
Subject: [PATCH] nix-prefetch-scripts: just don't depend on Nix

If we're running it from a build (fetchgit, fetchCargoVendor, etc),
none of the code paths that actually call Nix are hit.

If we're _not_ running it from a build, the user can reasonably be expected
to have a Nix present ambiently.

This avoids pulling Nix into the build closure of fetchCargoVendor,
and thus causing infrecs when Nix depends on Rust things.
---
 .../nix-prefetch-scripts/default.nix             | 16 +++-------------
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/pkgs/tools/package-management/nix-prefetch-scripts/default.nix b/pkgs/tools/package-management/nix-prefetch-scripts/default.nix
index 059b06362f16..040535f63ed8 100644
--- a/pkgs/tools/package-management/nix-prefetch-scripts/default.nix
+++ b/pkgs/tools/package-management/nix-prefetch-scripts/default.nix
@@ -13,18 +13,6 @@
   git-lfs,
   gnused,
   mercurial,
-  # FIXME: These scripts should not depend on Nix, they should depend on a
-  # `.nar` hasher compatible with Nix.
-  #
-  # The fact that these scripts depend on Nix means that e.g. Chromium depends
-  # on Nix.
-  #
-  # Also should be fixed:
-  # - prefetch-yarn-deps
-  # - nurl, nix-init
-  #
-  # Gridlock is one such candidate: https://github.com/lf-/gridlock
-  nixForLinking,
   subversion,
 }:
 
@@ -49,7 +37,6 @@ let
               ++ [
                 coreutils
                 gnused
-                nixForLinking
               ]
             )
           } \
@@ -66,6 +53,9 @@ let
     };
 in
 rec {
+  # No explicit dependency on Nix, as these can be used inside builders,
+  # and thus will cause dependency loops. When used _outside_ builders,
+  # we expect people to have a Nix implementation available ambiently.
   nix-prefetch-bzr = mkPrefetchScript "bzr" ../../../build-support/fetchbzr/nix-prefetch-bzr [
     breezy
   ];