| 12 Mar 2025 |
 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 |
| ruro | * 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 |
| ruro | * 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 |
| SomeoneSerge (back on matrix) | No I meant its counterpart in release-cuda.nix, the attrset with ... = linux definitions | 01:18:55 |
| SomeoneSerge (back on matrix) |
(and changed the // to lib.recursiveUpdate)
Just in case, this doesn't merge lists
| 01:19:38 |
| ruro | 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 |
| SomeoneSerge (back on matrix) | Yes that was the intent | 01:20:37 |
| ruro | Yes. That was the intended effect. | 01:20:38 |
| ruro | So that, for example, someone could do cudaPackages.some_package = [ ]; or something. | 01:21:27 |
| ruro | * So that, for example, someone could do cudaPackages.some_package = [ ]; in the "explicit" attrset or something. | 01:21:42 |
| SomeoneSerge (back on matrix) | I see | 01:21:46 |
| ruro | 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 |
| SomeoneSerge (back on matrix) | 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 |
| SomeoneSerge (back on matrix) | * 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 |
| SomeoneSerge (back on matrix) | * 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 |
