Skip to content

doc: add CUDA changes to 25.11 release notes #456510

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ConnorBaker wants to merge 1 commit into
base: master
Choose a base branch
from
Open

doc: add CUDA changes to 25.11 release notes #456510

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions doc/release-notes/rl-2511.section.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,16 @@
If a newer C++ library feature is not available on the default deployment target, you will need to increase the deployment target.
See the Darwin platform documentation for more details.

- A great number of changes to CUDA packaging:
- CUDA 13 is now available.
- Creation of CUDA package sets has been rewritten to remove module system evaluation.
Copy link
Contributor

@SomeoneSerge SomeoneSerge Oct 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm mildly skeptical about modules fully going away within the release cycle, tbh. The complete item would be "separate data and package set layers". The current progress towards that I'd maybe describe as "phase out the multiplex.nix builder in favour of [more explicit DI-style passing stuff from manifests to the builder]", but I don't claim to have the full picture as I'm still reading the diffs. Fwiw, seems like much of the logic of multiplex is still in place, moved to buildRedist/

Copy link
Contributor Author

@ConnorBaker ConnorBaker Oct 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Modules can always come back -- when there's a need for them :)

Building directly from the manifests cleans up and simplifies a lot of the logic, at the expense of essentially removing all validation of manifest structure.

buildRedist is essentially an updated version of the builder from generic, just with more checks and a healthy dose of offloading of various stages to a build script.

The multiplexing logic is gone entirely -- arguably it was a mistake to allow multiple versions of a single CUDA package within the package set.

Copy link
Contributor

@SomeoneSerge SomeoneSerge Oct 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The multiplexing logic is gone entirely -- arguably it was a mistake to allow multiple versions of a single CUDA package within the package set.

Yes, absolutely. Now this would be a good item for the changelog: it's an intentional change, it's likely persistent, it's high-level, it says something about the direction, etc, etc. Modules are an internal detail and they are not a problem in themselves, it's the incompatibility with DI that was the reason we wanted to get rid of the previous implementation...

- More packages provided by NVIDIA as binary archives (also called redistributables) are now available.
- Packages which fail to evaluate and depend on CUDA packages can produce helpful diagnostic messages during evaluation when `--show-trace --trace-verbose` are used.
- Package expressions are being updated to support building against older releases (where appropriate) to support out-of-tree consumers like [cuda-legacy](https://github.com/nixos-cuda/cuda-legacy).
- `_cuda.lib.licenses` was created to introduce several NVIDIA licenses new to Nixpkgs and used almost entirely within the CUDA package set.
- `_cuda.lib.getRedistSystem` had an API change to accommodate a new dependency on CUDA version.
Comment on lines +25 to +26
Copy link
Contributor

@SomeoneSerge SomeoneSerge Oct 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Disclaimer about internals&subject to change

Copy link
Contributor Author

@ConnorBaker ConnorBaker Oct 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's already documented in the Nixpkgs reference manual so I'm comfortable leaving it out.

Copy link
Contributor

@SomeoneSerge SomeoneSerge Oct 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see the disclaimers in the manual either, and I'd like to see them here as well anyway

- Many members of the CUDA package set are now marked as broken if [`config.cudaSupport`](https://nixos.org/manual/nixpkgs/stable/#opt-cudaSupport) is not set. This change was made to prevent the common mistake of using CUDA tooling to build a CUDA application but forgetting to enable [`config.cudaSupport`](https://nixos.org/manual/nixpkgs/stable/#opt-cudaSupport), resulting in an application which supports CUDA and dependencies which do not.
Copy link
Contributor

@SomeoneSerge SomeoneSerge Oct 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Many members of the CUDA package set are now marked as broken if [`config.cudaSupport`](https://nixos.org/manual/nixpkgs/stable/#opt-cudaSupport) is not set. This change was made to prevent the common mistake of using CUDA tooling to build a CUDA application but forgetting to enable [`config.cudaSupport`](https://nixos.org/manual/nixpkgs/stable/#opt-cudaSupport), resulting in an application which supports CUDA and dependencies which do not.
- Breaking: CUDA without [`config.cudaSupport`](https://nixos.org/manual/nixpkgs/stable/#opt-cudaSupport) is no longer supported. Building packages with CUDA dependencies without enabling `cudaSupport` globally is unsafe and often leads to inconsistent deployments, such as e.g. mixing CUDA-enabled `torchvision` with CPU-only `torch`. Starting with this release, the only supported way to use CUDA in Nixpkgs is `import <nixpkgs> { config.cudaSupport = true; }`.

And mv to the top


- LLVM has been updated from 19 to 21.

## Backward Incompatibilities {#sec-nixpkgs-release-25.11-incompatibilities}
Expand Down Expand Up @@ -106,6 +116,10 @@

- `cudaPackages.cudatoolkit-legacy-runfile` has been removed.

- `_cuda.lib.getRedistSystem` had an API change to accommodate a new dependency on CUDA version.

- Many members of the CUDA package set are now marked as broken if [`config.cudaSupport`](https://nixos.org/manual/nixpkgs/stable/#opt-cudaSupport) is not set. This change was made to prevent the common mistake of using CUDA tooling to build a CUDA application but forgetting to enable [`config.cudaSupport`](https://nixos.org/manual/nixpkgs/stable/#opt-cudaSupport), resulting in an application which supports CUDA and dependencies which do not.
Copy link
Contributor

@SomeoneSerge SomeoneSerge Oct 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Many members of the CUDA package set are now marked as broken if [`config.cudaSupport`](https://nixos.org/manual/nixpkgs/stable/#opt-cudaSupport) is not set. This change was made to prevent the common mistake of using CUDA tooling to build a CUDA application but forgetting to enable [`config.cudaSupport`](https://nixos.org/manual/nixpkgs/stable/#opt-cudaSupport), resulting in an application which supports CUDA and dependencies which do not.
- CUDA without global `config.cudaSupport` is no longer supported, cf. the ["Highlights"](#sec-nixpkgs-release-25.11-highlights) section.


- `conduwuit` was removed due to upstream ceasing development and deleting their repository. For existing data, a migration to `matrix-conduit`, `matrix-continuwuity` or `matrix-tuwunel` may be possible.

- `asciidoctor-with-extension` had its `asciidoctor-mathematical` extension removed, because it fails to build, and it is not maintained properly.
Expand Down
Loading