| 7 May 2025 |
 connor (he/him) (UTC-7) | It does seem that the current practice in tree is to call them overrides; honestly I'm not sure that anyone is really digging into the CUDA packaging outside of a few people in this room ;) | 23:08:39 |
 SomeoneSerge (Ever OOMed by Element) | Well that's exactly how lua and node "overrides" are used | 23:10:03 |
| SomeoneSerge (Ever OOMed by Element) | But the ordering (potential lack of commutativity) issues and the fact they are matched on pname rather than on attribute name has me hesitating | 23:11:01 |
| SomeoneSerge (Ever OOMed by Element) | Another note: node-packages/overrides.nix uses .override all over, whereas lua-modules/overrides.nix makes a mixed usage of .overrideAttrs and .override. Moreover, if I were to type the content of such an overrides.nix file, I'd say that it evaluates into an "overlay", which I'd say is another word for "extension" in the sense of composeMultipleExtensions | 23:13:23 |
| connor (he/him) (UTC-7) | Ah yeah, they are typically overlays, and I agree that overlay is synonymous with extension | 23:15:25 |
| SomeoneSerge (Ever OOMed by Element) | Do "overlays"/"extensions" consist of "overrides"? Well not quite, because we cannot easily take an overlay: Overlay and extract an o: Override that can be applied to a particular package: p.override o. | 23:16:16 |
| SomeoneSerge (Ever OOMed by Element) | If you know in advance all of the names you need to put in prev for the overlay not to throw exception, you could in principle extract them, but that's kind of stretched | 23:17:12 |
| SomeoneSerge (Ever OOMed by Element) | I think I convinced myself that overrides.nix neither are "overrides" nor consist of "overrides" | 23:17:51 |
| SomeoneSerge (Ever OOMed by Element) | So maybe we keep your name and call it a day | 23:18:03 |
| connor (he/him) (UTC-7) | isn't that similar to what it does currently here https://github.com/NixOS/nixpkgs/blob/293a5c5051586eb28a7eb42ff2dc4fd9943258ed/pkgs/development/cuda-modules/cuda/overrides.nix#L2-L28? | 23:18:45 |
| SomeoneSerge (Ever OOMed by Element) | Well here overrides.nix are already called with a valid prev | 23:20:01 |
| connor (he/him) (UTC-7) | OH | 23:20:12 |
| connor (he/him) (UTC-7) | Ah okay I see what you mean | 23:20:17 |
| SomeoneSerge (Ever OOMed by Element) | But it's a good point that previously cuda's overrides.nix was used both for overrides and for new definitions | 23:21:31 |
| SomeoneSerge (Ever OOMed by Element) | I guess now these all can go to fixups/ and packages/ resp. | 23:21:46 |
| connor (he/him) (UTC-7) | In the cuda-packages rework, packages exists for things which must be built explicitly because they're not from a manifest (e.g., nccl and cudnn-frontend) -- all the packages which come from manifest files are added implicitly by way of traversing the manifest and transforming it into packages. | 23:25:37 |
| SomeoneSerge (Ever OOMed by Element) | Sure, and "must be built explicitly" = "new definitions"? | 23:26:18 |
| connor (he/him) (UTC-7) | At the least, I'd say "not in a manifest" -> "must be built explicitly"
Does "new definitions" mean things added by an extension, or something else | 23:27:46 |
| SomeoneSerge (Ever OOMed by Element) | Well in the context of what used to be something-like-an-overlay | 23:30:41 |
 Kevin Mittman | CMake and Nix are good friends or no? | 23:30:49 |
| SomeoneSerge (Ever OOMed by Element) | Besties | 23:31:01 |
| SomeoneSerge (Ever OOMed by Element) | But sometimes they feel the need for dramaclean separation of binaries for different platforms and they hurt each other | 23:31:50 |
| connor (he/him) (UTC-7) | CMake? Sure... mostly. rapids-cmake (https://github.com/rapidsai/rapids-cmake)? Absolutely not :( | 23:35:37 |
 Tristan Ross | CMake isn't my friend | 23:38:24 |
| connor (he/him) (UTC-7) | Alrighty, so I'm changing overrides back to fixups (and making a note about how there's no "fixup" for versioned packages since they only apply to the base package, by pname) and floating the imports in pkgs/top-level/cuda-packages.nix back down and inline | 23:38:42 |
| connor (he/him) (UTC-7) | Does that sound right SomeoneSerge (UTC+U[-12,12])? | 23:38:51 |
| SomeoneSerge (Ever OOMed by Element) | That's what I had in mind too | 23:44:34 |
| 8 May 2025 |
| connor (he/him) (UTC-7) | Alrighty, should be good once CI passes | 00:04:29 |
| connor (he/him) (UTC-7) | PyTorch still built, so that's good | 00:04:37 |
| SomeoneSerge (Ever OOMed by Element) | RE: Why
How do we know if we can assume that (pname, version, platform) always corresponds to a unique hash, e.g. that nvidia never publishes two different things under the same (versioned) name? (treating sbsa and jetson as different platforms)
Well so far I haven't found any exceptions: A v. B
| 02:32:49 |
