| 11 Mar 2025 |
|  gumby0811 set a profile picture. | 23:38:53 |
| 12 Mar 2025 |
 ruro | Any preferences on the alternative name for evalPackageSetPlatforms? ))) | 00:42:04 |
| ruro | I am leaning towards packageSetPlatforms... | 00:42:18 |
| ruro | * I am leaning towards just packageSetPlatforms... | 00:42:32 |
 SomeoneSerge (back on matrix) | stick: I was going through the missed notifications today and saw a whole bunch of merged cuda-related fixes and refactorings. That was nice:) | 00:43:02 |
| SomeoneSerge (back on matrix) | Well, looking at the file again, we have packageSets, so the platforms are also of multiple package set<b>s</b>, but that's inconvenient to type, so maybe psPlatforms? | 00:51:57 |
| SomeoneSerge (back on matrix) | And comparing to pkgs/top-level/release.nix they introduce packageJobs, but then just use the in-place map for pkgs | 00:52:26 |
| ruro | Maybe packagePlatforms then? I mean... the attrset specifies the platforms for each package, not for each package set. | 00:54:15 |
| ruro | * Maybe packagePlatforms then? I mean... this attrset specifies the platforms for each package, not for each package set. | 00:54:23 |
| ruro | It's a bit unfortunate that packagePlatforms is a function in pkgs/top-level/release.nix, but eh... | 00:56:23 |
| ruro | Nvm | 00:56:47 |
| ruro | It's also a function inherited from release-lib | 00:57:04 |
| ruro | * packagePlatforms is also a function inherited from release-lib | 00:57:19 |
| SomeoneSerge (back on matrix) | well, platforms for entire sets of packages, and the reason that stuff is in a separate variable is because individual packages are handled differently | 00:57:32 |
| ruro | Yeah... | 00:57:50 |
| ruro | Damn, naming things is hard | 00:58:00 |
| ruro | platformsForPackageSets? | 00:58:36 |
| SomeoneSerge (back on matrix) | Sure. Or... just keep the function application without a name xD | 00:59:21 |
| ruro | Or alternatively, we could rename packageSets to cudaPackageSets and then rename evalPackageSetPlatforms to cudaPackagePlatforms. | 00:59:21 |
| SomeoneSerge (back on matrix) | I guess the thought was we might start being less picky and start adding either subscopes?.. | 01:01:12 |
| ruro | On one hand this isn't very future proof because of potential future rocm and mkl support. On the other hand, the file is already called release-cuda, not release-unfree or something | 01:01:15 |
| SomeoneSerge (back on matrix) | Oh! I think I know why it was ${pset} = ... | 01:01:30 |
| SomeoneSerge (back on matrix) | Uhm no nevermind still doesn't make sense | 01:03:57 |
| ruro | Or maybe s/packageSets/recursivePackages/g and s/evalPackageSetPlatforms/recursivePackagePlatforms/g... | 01:06:25 |
| SomeoneSerge (back on matrix) | Oh! I didn't do it! xD | 01:08:11 |
| SomeoneSerge (back on matrix) | Git blame shows this was inherited from Frederik's refactoring | 01:08:46 |
| SomeoneSerge (back on matrix) |
recursivePackages
Right now the difference isn't just that it's "recursive" but also that we filter out the unsupported platforms, which we don't do for the packageJobs Can't say this was originally intended but you found a use for that 🤷
| 01:11:28 |
| SomeoneSerge (back on matrix) | 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 |
| ruro | 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 |
| ruro | Yes. I actually flipped the order when I implemented the filtering logic, but this change got thrown out with it. | 01:15:47 |
