python3Packages.warp-lang: fix CUDA build#419750
Conversation
|
CC @yzx9 this is a WIP PR where I'm trying to fix the CUDA build. Currently it's failing with an error that makes me think the wrong version of |
|
It looks like the version of libmathdx used is too new: https://github.com/NVIDIA/warp/blob/v1.7.2.post1/deps/libmathdx-deps.packman.xml |
cdee0f7 to
96233a1
Compare
There was a problem hiding this comment.
It’s good practice not to reference the package itself directly, as the test should respect overrides.
| warp-lang | |
| finalAttrs.finalPackage |
There was a problem hiding this comment.
Yep! But, the Python wrappers around mkDerivation don't accept fixed-points or extensions as arguments, only plain attribute sets. That's why you don't see any called with finalAttrs: { ... } -- they mostly use rec (which effectively breaks overriding attributes).
There have been multiple attempts in the past to support this functionality (most recently with the introduction of lib.customisation.extendMkDerivation: #234651).
Unfortunately, that hasn't been adopted by the python packaging yet: see #379602 and #271387.
And so we wait...
|
|
The update script was removed given the dependency on libmathdx, which is not easily updated. Signed-off-by: Connor Baker <ConnorBaker01@gmail.com>
96233a1 to
e5d0d6c
Compare
|
Unfortunately, not really :( Lack of documentation has long been one of the pain points facing the CUDA packaging in Nixpkgs. Most of what I (and I assume the other CUDA maintainers) know about the packaging comes from a combination of having written it, reviewed it, or read through the implementation while trying to debug it. Making matters worse, most of the larger projects (OpenCV, PyTorch, ONNX, etc.) are far off and away from the packaging happy path because they involve multiple languages, build systems, and wrappers around those build systems (e.g., Bash build scripts which wrap Python build scripts which wrap CMake). Most recently, @SomeoneSerge and myself have been trying to rewrite the way the package set is created and updated to make it more maintainable, as well as more extensible for out-of-tree users. I've also been focusing on cleaning up the re-packaging of NVIDIA's binary archives and the setup hooks which underpin most of our package discovery and propagation. As part of that work, I've been trying to write documentation (https://github.com/ConnorBaker/cuda-packages/tree/main/pkgs/development/cuda-modules and https://github.com/ConnorBaker/cuda-packages/blob/main/doc/language-frameworks/cuda.section.md) but it's exhausting, regularly a very low priority, and hard to keep up to date or accurate (for example, most of what's there now is incorrect with respect to what exist in the repo, much less what exists here in Nixpkgs). All that said, we'd love to have more people involved with Nixpkgs and CUDA -- please feel free to join us in the CUDA matrix channel: https://matrix.to/#/#cuda:nixos.org |
Most of these changes were taken from https://github.com/ConnorBaker/cuda-packages/blob/2fc8ba8c37acee427a94cdd1def55c2ec701ad82/pkgs/development/python-modules/warp/default.nix#L56-L65.
I confirmed that I was able to build all variants and run all
passthru.testson my NixOS desktop with an NVIDIA GPU.Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.