NixOS CUDA | 283 Members | |
| CUDA packages maintenance and support in nixpkgs | https://github.com/orgs/NixOS/projects/27/ | https://nixos.org/manual/nixpkgs/unstable/#cuda | 58 Servers |
| Sender | Message | Time |
|---|---|---|
| 12 Mar 2025 | ||
| Btw it was also maybe a bad move (on my side this time I think) to make these filtered jobs override the manually specified packageJobs | 01:14:19 | |
If you mean the attrset with explicitly specified packages, then it makes sense not to filter out platforms when they are explicitly spelled out. If you mean packageJobs in release.nix, then I think that it does filter it out by using release-lib.getPlatforms. | 01:15:00 | |
| Yes. I actually flipped the order when I implemented the filtering logic, but this change got thrown out with it. | 01:15:47 | |
* Yes. I also noticed this and so I actually flipped the order (and changed the // to lib.recursiveUpdate) when I implemented the filtering logic, but this change got thrown out with it. | 01:18:29 | |
* Yes. I also noticed this and so I actually flipped the order (and changed the // to lib.recursiveUpdate) when I originally implemented the filtering logic, but this change got thrown out with it. | 01:18:44 | |
No I meant its counterpart in release-cuda.nix, the attrset with ... = linux definitions | 01:18:55 | |
Just in case, this doesn't merge lists | 01:19:38 | |
Yeah. Then I think that it makes sense not to filter them out automatically. If someone explicitly added somepackage = linux; then I think that we should have an eval error if somepackage doesn't support linux. | 01:20:14 | |
| Yes that was the intent | 01:20:37 | |
| Yes. That was the intended effect. | 01:20:38 | |
So that, for example, someone could do cudaPackages.some_package = [ ]; or something. | 01:21:27 | |
* So that, for example, someone could do cudaPackages.some_package = [ ]; in the "explicit" attrset or something. | 01:21:42 | |
| I see | 01:21:46 | |
| If you want, I can add it back in. But I think that this reordering was one of the reasons for the indentation change that you wanted to avoid))) | 01:23:08 | |
Well, ok. Let's swap the order. And for the packageSets variable and for evalPackageSet they actually don't seem to be doing anything useful. The packageSets there really only serves the purpose of automatically identifying the cuda package sets, so let's rename it to cudaPackageSets as, I think, you've already suggested. Let's not introduce the extra variable for evalPackageSet nor for its image, but instead just use packagePlatforms directly in jobs = let in HERE // { ... = linuxl } | 01:24:30 | |
* Well, ok. Let's swap the order. And for the packageSets variable and for evalPackageSet they actually don't seem to be doing anything useful. The packageSets there really only serves the purpose of automatically identifying the cuda package sets, so let's rename it to cudaPackageSets as, I think, you've already suggested. Let's not introduce the extra variable for evalPackageSet nor for its image, but instead just use packagePlatforms directly in jobs = let in HERE // { ... = linuxl } | 01:24:37 | |
* Well, ok. Let's swap the order. And for the packageSets variable and for evalPackageSet they actually don't seem to be doing anything useful. The packageSets there really only serves the purpose of automatically identifying the cuda package sets, so let's rename it to cudaPackageSets as, I think, you've already suggested. Let's not introduce the extra variable for evalPackageSet nor for its image, but instead just use packagePlatforms directly in jobs = let in HERE // { ... = linux; } | 01:24:42 | |
| wdyt? | 01:24:45 | |
| If we want to add any other package set well we just add another function call there 🤷 | 01:25:52 | |
Ah we maybe want to give a name to mapTestOn . packagePlatforms? | 01:28:28 | |
| How about
| 01:36:27 | |
| Also, if you have any ideas on how to remove the "load-bearing comment" without changing the indentation - be my guest))) | 01:38:26 | |
| * How about
| 01:41:00 | |
| * How about
| 01:41:55 | |
ruro: I'm ok with that, I just thought applying mapAttrs packagePlatforms is not such a complex thing that we really need to be so verbose about it | 08:50:34 | |
| 14:27:37 | ||
| 17 Mar 2025 | ||
| Any ideas why tensorrt from 24.11 is failing to build? I downloaded and imported the sources into nix store as instructed, but it doesn't want to unpack it.
| 12:29:56 | |
The wheel in the archive is called tensorrt-10.3-cp312-none-linux_x86_64.whl, so not sure what's going on | 12:31:21 | |
* The wheel in the archive is called tensorrt-10.3.0-cp312-none-linux_x86_64.whl, so not sure what's going on | 15:14:31 | |
| 16:10:28 | ||