The final stage asserted
assert prevStage.libiconv == prevStage.darwin.libiconv;
On Darwin `libiconv` is `darwin.libiconv`, so this compares a value with
itself. Nix does not notice: `eqValues` short-circuits only on pointer
identity of the two value slots, and these are two slots that resolve to
one attribute set. It therefore falls through to the derivation case,
which compares `outPath`.
`lib.extendDerivation` guards `outPath` behind the derivation's validity,
which reads `config.allowUnfree`, so the assertion demanded a `config`
option while the package set was still being assembled. When `config` is a
function it is passed `pkgs`, and the loop closes:
(import <nixpkgs> {
system = "aarch64-darwin";
config = { pkgs, lib, ... }: { allowUnfree = lib.isAttrs pkgs; };
}).config.allowUnfree
failed with an infinite recursion on Darwin while evaluating on Linux,
whose stdenv never forces a derivation that early. It now evaluates on
both.
Keep checking the invariant, from `tests.stdenv` instead. By then the
package set is complete, so forcing `outPath` is just a read.
The other twelve assertions in the stage read `passthru` and
`stdenv.cc.cc`, which are ungated, and stay where they are.
Assisted-by: claude-code with claude-opus-5[1m]-high
Reapplies #517762, reverted in #518791.
Pass config = {} explicitly to prevent impure.nix from filling it
from NIXPKGS_CONFIG. This is equivalent to the old behavior where
inherit (cfg) config always overrode the impure.nix default.
When setting a prefix for a path-like environment variable, the
deduplication code in set_env_prefix reads past the NUL byte at the end
of the env val and into the next entry. This corrupts the resultant env
value with data from the next env var, or other data sitting after it.
Fixup-state-db is effectively only used in fetchPnpmDeps.
We previously included the SQLite database in the FOD, it was first
problematic as it produced different hashes on linux and darwin, but
SQLite version updates have a higher chance of changing the DB format
and break our hashes, that just happened with the 3.53.1 -> 3.53.3 bump.
Nowadays fetchPnpmDeps relies on the SQL dump of the database which is
more stable, but in the past hashes were broken once.
The point is, we no longer rely on the raw DB, but only it's dump, so
it's safe to assert for that in this test.
This drops the stack trace truncated marker from all the fixtures as
those aren't reliable. What we care about is the exact error message
and not the stack traces.
This drops matching on the truncated stack trace marker as that only
appears if the stack trace is actually long enough. In some cases the
stack trace is simply too short so Nix prints it out entirely. Then
the tests fail and I'm unhappy.
This was caused by a90d993610 which to the best of my understanding
forces the error message very early in the eval and thus doesn't have
a very long stack trace.
Add a Hugging Face Hub repository fetcher with support for model, dataset, and space repositories, custom Hub domains, tags and revisions, and the relevant fetchgit options.
Select storage through a backend argument. Git LFS is implemented through fetchgit; Xet is the default to match Hugging Face but fails explicitly until its implementation lands.
Expose the helper from pkgs, document its API, and register evaluation and fixed-output fetch tests.
Assisted-by: OpenAI Codex (GPT-5)
In 53cd6f263c the oldestSupportedRelease
version was bumped to 26.05 which caused the meta/problems tests to
fail because the `config.allowBrokenPredicate` is now deprecated and
the code is warning about it.
SQLite update changed the format of the raw DB (which this test uses)
and also the dump format. Supported `fetcherVersion`s in `fetchPnpmDeps`
no longer rely on the raw DB file being stable, so it's fine to update this hash.
tests-fetchgit was implemented in commit 4e37d03ba2
("fetchgit: reference hash from finalAttrs.hash"),
but not attach to tests.overriding,
hence this fix.
