The global virtual store contains package payloads that may use JSONC, as well as generated bin shims containing build-directory paths. These files should not be part of the fixed-output dependency store.
Redirect virtual-store materialization to a temporary directory. pnpmConfigHook reconstructs it offline from the archived content-addressable store.
Assisted-by: pi coding agent (GPT-5.6-sol, GPT-6-sol)
Add
meta.problems.buildPythonPackage-internal-disabled-overridePythonAttrs
when <pkg>.overridePythonAttrs taking deprecated argument disabled.
buildPythonPackage and buildPythonApplication
still takes argument disabled,
transformed with makeOverridablePythonPackages.
Co-authored-by: Matt Sturgeon <matt@sturgeon.me.uk>
Transparently convert the { disabled = true; } to
meta.problems.unsupportedPython
and remove the `disabled` argument,
such that <pkg>.overridePythonAttrs can always
mitigate unsupportedPython by removing it from meta.problems
Co-authored-by: Eman Resu <ellakalle6@gmail.com>
Co-authored-by: Matt Sturgeon <matt@sturgeon.me.uk>
Remove overrideStdenvCompat from python-packages-base.nix
Add meta.problems.buildPythonPackage-internal-stdenv
when getting the stdenv argument
to make it an package evaluation error.
Add a test case in tests.overriding
(overridePythonAttrs-deprecated-arg-stdenv)
asserting that the problem appears when overriding with
<pkg>overridePythonAttrs with the deprecated stdenv argument.
To avoid regressions such as the one introduce in 12.7 (see parent
commit), add a few platform specific dependencies to our test to make
sure these are fetched on every platform no matter what.
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
buildVimPlugin always set its own installPhase, so one passed to it
never ran and the plugin silently got the whole source tree instead.
Use the caller's installPhase when set, like trivialBuild and
buildGoModule do, and keep the current one as the default. Plugins
that don't set installPhase are unchanged.
With dontUnpack there is no source directory to install from, so
installPhase copied $NIX_BUILD_TOP instead: env-vars, .attrs.json, and
.attrs.sh ended up in the plugin and pulled the whole stdenv into its
closure. Skip the copy in that case and leave installing files to the
caller's phases. Plugins that unpack keep an identical installPhase.
Fixes#508465
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.
