darwin.moltenvk: fix the eval on linux

[trofi]

Without the change the eval fails as:

$ nix eval --impure --expr 'with import ./. { system = "x86_64-linux"; }; darwin.moltenvk.NIX_CFLAGS_COMPILE'
error:
   … in the condition of the assert statement
     at pkgs/stdenv/generic/make-derivation.nix:716:11:
      715|           n: v:
      716|           assert assertMsg (isString v || isBool v || isInt v || isDerivation v)
         |           ^
      717|             "The `env` attribute set can only contain derivation, string, boolean or integer attributes. The `${n}` attribute is of type ${builtins.typeOf v}.";

   … in the left operand of the OR (||) operator
     at lib/asserts.nix:39:31:
       38|   # TODO(Profpatsch): add tests that check stderr
       39|   assertMsg = pred: msg: pred || builtins.throw msg;
         |                               ^
       40|

   (stack trace truncated; use '--show-trace' to show the full, detailed trace)

   error: expected a set but found null: null

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[reckenrode]

Ah, right. MoltenVK is Darwin-only, but it still gets eval’d on other platforms. The fix LGTM.

[emilazy]

Shouldn't the meta.platforms line guard against it? I've fixed other interpolation issues that way.

[trofi]

Shouldn't the meta.platforms line guard against it? I've fixed other interpolation issues that way.

I think it depends on the attributes. Today stdenv.mkDerivation does not insert platform evaluation into every single attribute (maybe it should, but I suspect there are circular dependencies). As a result some attributes are accessible for everyone:

nix-repl> darwin.moltenvk.version
"1.2.11"

and some are not:

nix-repl> darwin.moltenvk.outPath
 error: Package ‘MoltenVK-1.2.11’ in pkgs/by-name/mo/moltenvk/package.nix:205 is not available on the requested hostPlatform:
         hostPlatform.config = "x86_64-unknown-linux-gnu"
         package.meta.platforms = [
           "x86_64-darwin"
           "aarch64-darwin"
         ]

[emilazy]

Right, makes sense. Is the worry that this will break Hydra or some other automated tooling that can’t catch the error? It seems impractical to ensure that attributes of a derivation can reliably be evaluated on unsupported meta.platforms, and it causes enough headaches when it does break channel eval that I’d rather move in the direction of expecting it to work less rather than more. But if this is actually going to break something that isn’t easily fixable then of course we should merge this to fix it.

[trofi]

I would say the nowadays tooling is too good at skipping errors :) Attributes disappear all the time (especially tests) due to simple mistakes that break evaluation.

I'm running https://trofi.github.io/posts/309-listing-all-nixpkgs-packages.html time to time to make sure most attributes evaluate without uncatchable exceptions (and to be able to build reverse dependency lists with a bit more confidence that they don't skip too much). The post accumulated about 100 past PRs over 1.5 years. Those show sometimes real (my favourite) sometimes benign (this case) errors.

In nixpkgs a derivation can hide anywhere (and most attributes can also be used directly by users). Almost all of nixpkgs evaluates without problems down to 4 levels of attributes nesting (with a few exceptions).

If this kind of fixes is too much to bear I can skip darwin.* namespace and keep the hacks locally. Though it's a bit hard when it gets referenced directly from the outside. Or I can abandon the whole endeavour if the result does not look useful. I have no intention wasting peoples' time.

[emilazy]

Fair enough! I don’t object to the principle here, but I am more uncertain about how we can make it work in practice. For instance, #400427 is going to introduce more of this, because ${libGL} is sensible to do on Linux but not on Darwin where it’s null. libintl is precedent for a package that is null on platforms where it’s irrelevant. We could point things at random stub package instead – but then on the wrong platforms they’ll just interpolate to nonsense results rather than throwing an error. We probably do want ${libGL} to break loudly on packages that are trying to support Darwin, but we don’t want to burden every Linux package with guarding uses of it.

So I’m not sure what the best solution here is – I assume merging that PR is going to break your tooling, which I think is interesting and valuable, but it seems like when it comes to platform differences we approach a situation where we say platforms = coolOS; and then also have to do if isCoolOS, lib.optionals propertyAlwaysTrueOnCoolOS, and so on. It seems like a platform could conceivably hang basically arbitrary things off stdenv that would complicate this, so I wonder if tooling should at least try to bail out quickly for the case of an unsupported platforms value or something marked as broken.

On the other hand, if very few things in Nixpkgs cause this to begin with, then maybe we’re doing something wrong and should stop making it worse! But I wonder how much of that is just that Darwin generally has to support the kinds of things Linux packages expect by necessity, and there are relatively few Darwin‐only packages…

[emilazy]

FWIW, I’ve merged #400427 because of the upcoming freeze, but I’m open to revising the specific approach based on these concerns if we can figure out what makes the most sense.

[trofi]

I saw no new darwin.* eval failures after #400427. But today I only evaluate for system = "x86_64-linux". I never seriously tried anything else (partly because pkgsCross.* is a good canary in the mine of so many pre-existing failures) mostly due to time constraints.

[jopejoe1]

Fixing eval issues is always nice, feel free to ping me on any other prs fixing eval issues.