| 6 Feb 2025 |
|  djacu joined the room. | 15:49:57 |
 ruro | This might be a stupid question, but when the nixpkgs manual says
All new projects should use the CUDA redistributables available in cudaPackages in place of cudaPackages.cudatoolkit
does it mean that individual derivations from cudaPackages.* should be manually added to buildInputs/nativeBuildInputs. For example, would this mean that I should just manually add cuda_nvcc to nativeBuildInputs.
What if the upstream package expects a single CUDA_PATH path containing all the cuda dependencies? I think, I saw some people using buildEnv to collect all of the required binaries/libraries under a single path, but I am not sure if this is the most elegant way to do this (also, it's not immediately clear, how would a single CUDA_PATH interact with cross compilation).
| 16:54:13 |
| ruro | * This might be a stupid question, but when the nixpkgs manual says
All new projects should use the CUDA redistributables available in cudaPackages in place of cudaPackages.cudatoolkit
does it mean that individual derivations from cudaPackages.* should be manually added to buildInputs/nativeBuildInputs. For example, would this mean that I should just manually add cuda_nvcc to nativeBuildInputs.
What if the upstream package expects a single CUDA_PATH path containing all the cuda dependencies? I think, I saw some people using buildEnv to collect all of the required binaries/libraries under a single path, but I am not sure if this is the most elegant way to do this (also, it's not immediately clear, how would a single CUDA_PATH interact with cross compilation).
| 16:54:19 |
| ruro | * This might be a stupid question, but when the nixpkgs manual says
All new projects should use the CUDA redistributables available in cudaPackages in place of cudaPackages.cudatoolkit
does it mean that individual derivations from cudaPackages.* should be manually added to buildInputs/nativeBuildInputs. For example, would this mean that I should just manually add cuda_nvcc to nativeBuildInputs?
What if the upstream package expects a single CUDA_PATH path containing all the cuda dependencies? I think, I saw some people using buildEnv to collect all of the required binaries/libraries under a single path, but I am not sure if this is the most elegant way to do this (also, it's not immediately clear, how would a single CUDA_PATH interact with cross compilation).
| 16:54:58 |
 SomeoneSerge (matrix works sometimes) | Honestly, I've no idea what license, if any, applies to torch-bin | 17:24:28 |
| SomeoneSerge (matrix works sometimes) | Yes, or we could just agree that testing for insecure dependencies is out of scope for hydra | 17:26:09 |
| SomeoneSerge (matrix works sometimes) | I expect static and devrt to be in .dev's propagatedBuildInputs | 17:27:54 |
