cudaPackages_11_0.autoAddCudaCompatRunpath.libcudaPath: fix the eval

[trofi]

Addresses #405031 (comment). Without the change direct access to the attribute fails to eval as:

$ nix eval --impure --expr 'with import ./. {}; cudaPackages_11_0.autoAddCudaCompatRunpath.libcudaPath'
evaluation warning: CUDA versions older than 12.0 will be removed in Nixpkgs 25.05; see the 24.11 release notes for more information
error:
   … while evaluating the attribute 'autoAddCudaCompatRunpath.libcudaPath'
     at pkgs/development/cuda-modules/packages/autoAddCudaCompatRunpath/package.nix:16:5:
       15|   substitutions = {
       16|     libcudaPath = if cuda_compat then "${cuda_compat}/compat" else null;
         |     ^
       17|   };

   … while evaluating a branch condition
     at pkgs/development/cuda-modules/packages/autoAddCudaCompatRunpath/package.nix:16:19:
       15|   substitutions = {
       16|     libcudaPath = if cuda_compat then "${cuda_compat}/compat" else null;
         |                   ^
       17|   };

   error: expected a Boolean but found null: null
   at pkgs/development/cuda-modules/packages/autoAddCudaCompatRunpath/package.nix:16:19:
       15|   substitutions = {
       16|     libcudaPath = if cuda_compat then "${cuda_compat}/compat" else null;
         |                   ^
       17|   };

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.

[trofi]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 406668

---

x86_64-linux

[SomeoneSerge]

Hm I thought this should've been sufficient: https://github.com/NixOS/nixpkgs/pull/405031/files#diff-f0756e113cff4d541c62e50496aca47492801463cb75266b75732935906ffe63R19-R27

[SomeoneSerge]

Tldr: we've had this exact patch before, I'm hoping to eliminate this hacks by setting the platforms right

[ConnorBaker]

If a package is marked as broken or is on an unsupported platform, should we expect arbitrary attributes of that package to evaluate?

[SomeoneSerge]

As I mention in #405031, my understanding is we only ever enforced that CI must pass (tautology intended), and CI only ever cared about eval errors in "supported" packages.

I'm all for adopting a stricter convention at least at the cudaPackages level, we'd just have to first ensure it's universally applied (notoriously violated by e.g. our handling of cudnn), and then ensure it stays that way (need CI).

We've nominally adopted the rule that namesets of cudaPackages should be stable (if one instance has a cudnn_8_9 attribute, all instnaces must have one, albeit marked broken or unsupported), we failed to enforce it. Specifically libcudaPath a fringe case because nobody actually ever references it outside the definition, but it would be sure nice not to have it throwing.

For now I propose we do an ugly fix along the lines of #406207 (comment)

More generally, one goal of #406740 is to fix a static set of names guaranteed to exist across all cudaPackages instances

[winterqt]

If a package is marked as broken or is on an unsupported platform, should we expect arbitrary attributes of that package to evaluate?

I don't think so -- there are plenty of packages in-tree that fail to eval under those two cases.

FWIW: my CI work (which I expect to PR some time today) catches the issue that #406207 fixed, but not this one, because it has no supported platforms.

[winterqt]

@trofi If I may ask, how did you even find this if you're not just blanket evaling everything while allowing broken and unsupported platforms?

[SomeoneSerge]

blanket evaling everything

If not that, we should totally start doing so, and recording the results in some public index

…

On 13/05/2025 18.22, Winter wrote: blanket evaling everything

-- SomeoneSerge <https://someonex.net>

[trofi]

@trofi If I may ask, how did you even find this if you're not just blanket evaling everything while allowing broken and unsupported platforms?

I blanket-eval everything :) https://trofi.github.io/posts/309-listing-all-nixpkgs-packages.html

I usually run ./all-attrs-iter.bash -I nixpkgs=~/n --arg maxDepth 4 --arg verbose 3 --arg ignoreDrvAttrs false --arg stepLimit 10000 daily. Current script: https://github.com/trofi/nixpkgs-overlays/blob/main/lib/all-attrs-iter.bash

[trofi]

Note that normally packages on unsupported platform generate the exceptions that you can catch (and ignore) with builtins.tryEval. I ignore those. The problem here is that it's an uncatchable null-dereference error not guarded by any platform check.

[SomeoneSerge]

builtins.tryEval

That's a good distinction! Anyway, if you're ok with the alternative "fix" I pushed feel free to squash & merge

[trofi]

You change fixes eval for me as well. Dropped my patch.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/5561