| 7 May 2025 |
 SomeoneSerge (matrix works sometimes) | 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 (matrix works sometimes) | 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) | Ah yeah, they are typically overlays, and I agree that overlay is synonymous with extension | 23:15:25 |
| SomeoneSerge (matrix works sometimes) | 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 (matrix works sometimes) | 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 (matrix works sometimes) | I think I convinced myself that overrides.nix neither are "overrides" nor consist of "overrides" | 23:17:51 |
| SomeoneSerge (matrix works sometimes) | So maybe we keep your name and call it a day | 23:18:03 |
| connor (he/him) | 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 (matrix works sometimes) | Well here overrides.nix are already called with a valid prev | 23:20:01 |
| connor (he/him) | OH | 23:20:12 |
| connor (he/him) | Ah okay I see what you mean | 23:20:17 |
| SomeoneSerge (matrix works sometimes) | 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 (matrix works sometimes) | I guess now these all can go to fixups/ and packages/ resp. | 23:21:46 |
| connor (he/him) | 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 (matrix works sometimes) | Sure, and "must be built explicitly" = "new definitions"? | 23:26:18 |
| connor (he/him) | 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 (matrix works sometimes) | Well in the context of what used to be something-like-an-overlay | 23:30:41 |
 Kevin Mittman (jetlagged/UTC-7) | CMake and Nix are good friends or no? | 23:30:49 |
| SomeoneSerge (matrix works sometimes) | Besties | 23:31:01 |
| SomeoneSerge (matrix works sometimes) | 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) | 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) | 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) | Does that sound right SomeoneSerge (UTC+U[-12,12])? | 23:38:51 |
| SomeoneSerge (matrix works sometimes) | That's what I had in mind too | 23:44:34 |
| 8 May 2025 |
| connor (he/him) | Alrighty, should be good once CI passes | 00:04:29 |
| connor (he/him) | PyTorch still built, so that's good | 00:04:37 |
| SomeoneSerge (matrix works sometimes) | 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 |
| SomeoneSerge (matrix works sometimes) | (didn't load all manifests yet tho) | 02:33:21 |
| connor (he/him) | Fair question; I don’t think we do.
Is there a concern you had in mind?
For what it’s worth, I’ve seen them use the “source” and “linux-all” platform (meta-platform?) to indicate a package works on multiple platforms rather than having an entry for each (all with the same hash). In the rework I give those preferential treatment since they’re agnostic and don’t seem to occur alongside other variants of the package: https://github.com/ConnorBaker/cuda-packages/blob/7731ebdf397c5ce123571abf2dc41ebac86237d3/pkgs/development/cuda-modules/packages/redist-builder/package.nix#L102 | 04:54:54 |
