| 7 May 2025 |
 SomeoneSerge (back on matrix) | 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 (back on matrix) | 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 (back on matrix) | 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 (back on matrix) | 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 (back on matrix) | Well in the context of what used to be something-like-an-overlay | 23:30:41 |
 Kevin Mittman (UTC-8) | CMake and Nix are good friends or no? | 23:30:49 |
| SomeoneSerge (back on matrix) | Besties | 23:31:01 |
| SomeoneSerge (back on matrix) | 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 (back on matrix) | 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 (back on matrix) | 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 (back on matrix) | (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 |
| connor (he/him) | Okay bed time for me.
Tomorrow will include work on introducing the setup hook changes | 04:59:20 |
| connor (he/him) | Thank you for the fixes Serge! | 16:07:04 |
| SomeoneSerge (back on matrix) | Sure, thank you! | 17:10:55 |
| SomeoneSerge (back on matrix) | I avoided force-pushes. Do you think we should squash? | 17:11:27 |
| Kevin Mittman (UTC-8) | In reply to @ss:someonex.net
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
There is a policy of version uniqueness. Unfortunately, enforcement is limited | 18:26:54 |
| Kevin Mittman (UTC-8) | In reply to @connorbaker:matrix.org
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 driver_assistant is a pure Python script, hence linux-all. and cudnn_samples is source code, that would ideally be posted on Github | 18:31:25 |
| SomeoneSerge (back on matrix) | Well I want functionality for "merging" a set of manifests, rather than having single cuda manifest first spawn a package set, which is then extended with other components like cudnn. I think that suggests a merged domain of "package( recipe)s" which the future package set can grab stuff from. Finally, if things are to share a scope, how do we know they don't compete for the same spot? ^^^ | 18:35:02 |
| SomeoneSerge (back on matrix) | Yeah as long as we ensure observability on our side I'm fine making this an assumption | 18:37:23 |
