| 18 Sep 2025 |
 connor (he/him) (UTC-7) | I’ve got a long day ahead of me, but SomeoneSerge (back on matrix)to follow back up on earlier, in https://github.com/NixOS/nixpkgs/pull/437723 I made changes to config to allow NVIDIA’s licenses when cudaSupport is true. That means users can build CUDA packages without using the impure flag and providing a custom config with allowUnfree, allowUnfreePredicate, or allowlistedLicenses, just by building off of pkgsCuda or pkgsForCudaArch. I think that’s important for the UX. Also, since we don’t need the impure flag we can benefit from evaluation caching.
Like all Nixpkgs “variants” (the term I’ve seen used to describe different instantiations of Nixpkgs within Nixpkgs, like pkgsLLVM), there is an evaluation cost to using those attributes, but it beats repeatedly editing a config.nix file.
Of course, for out-of-tree consumers (like user flakes) configuring Nixpkgs exactly once when it is imported is preferred, but not everyone can or wants to do that. | 16:13:20 |
| connor (he/him) (UTC-7) | In further iterations I’ll try to move the licenses into lib.licenses so they’re available there instead of in _cuda.lib.licenses; we should be using those licenses instead of ad-hoc ones anyway. | 16:15:14 |
| connor (he/him) (UTC-7) | Which brings me to another great irritation — should older versions of software refer specifically to older versions of the license? Do we need to do something to preserve them or vendor them in tree? If the license contains clauses allowing it to be updated without notice, is that enforceable everywhere? | 16:17:41 |
| connor (he/him) (UTC-7) | * Which brings me to another great irritation — should older versions of software refer specifically to older versions of the license? Do we need to do something to preserve them or vendor them in tree? If the license contains clauses allowing it to be updated without notice, is that enforceable everywhere?
Ignore that; licenses are complicated and I can’t give myself a migraine this early.
| 16:18:22 |
| 4 Aug 2022 |
|  Winter (she/her) joined the room. | 03:26:42 |
| Winter (she/her) | (hi, just came here to read + respond to this.) | 03:28:52 |
 tpw_rules | hey. i had previously sympathzied with samuela and like i said before had some of the same frustrations. i just edited my github comment to add "[CUDA] packages are universally complicated, fragile to package, and critical to daily operations. Nix being able to manage them is unbelievably helpful to those of us who work with them regularly, even if support is downgraded to only having an expectation of function on stable branches." | 03:29:14 |
| Winter (she/her) | In reply to @tpw_rules:matrix.org
i'm mildly peeved about a recent merging of something i maintain where i'm pretty sure the merger does not own the expensive hardware required to properly test the package. i don't think it broke anything but i was given precisely 45 minutes to see the notification before somebody merged it ugh, 45 minutes? that's... not great. not to air dirty laundry but did you do what samuela did in the wandb PR and at least say that that wasn't a great thing to do? (not sure how else to word that, you get what i mean) | 03:30:23 |
| tpw_rules | no, i haven't yet, but i probably will | 03:31:03 |
| Winter (she/her) | i admittedly did that with a PR once, i forget how long the maintainer was requested for but i merged it because multiple people reported it fixed the issue. the maintainer said "hey, don't do that" after and now i do think twice before merging. so it could help, is what i'm saying. | 03:31:50 |
| tpw_rules | i'm not sure what went wrong with the wandb PR anyway, i think it was just a boneheaded move on the maintainer's part | 03:32:10 |
| Winter (she/her) | (it was also simple enough that it was fine and the maintainer said it looked good after) | 03:32:15 |
| tpw_rules | * i'm not sure what went wrong with the wandb PR anyway, i think it was just a boneheaded move on the merger's part | 03:32:19 |
| tpw_rules | but i thought most of the frustration was around packages which don't really involve CUDA breaking the fragile CUDA packages, and i'm not sure how the warning helps in this case. it's not like nixpkgs-review prints out the comments. maybe i'm wrong. but it is a legitimate problem | 03:34:19 |
| Winter (she/her) | the frustration that i see is that people are touching packages that he maintains, am i missing further context here? | 03:35:09 |
| tpw_rules | did you ever see this? https://discourse.nixos.org/t/nixpkgss-current-development-workflow-is-not-sustainable/18741 | 03:35:43 |
| Winter (she/her) | oh yes i did | 03:35:49 |
| Winter (she/her) | but that's not what the topic of this PR/the notice is, though? | 03:36:11 |
| Winter (she/her) | this wouldn't help that | 03:36:14 |
| Winter (she/her) | ~~is that what you're saying and i'm just lagging behind~~ | 03:36:27 |
| tpw_rules | no it wouldn't, but it reads to me like that's the underlying problem and this is a manifestation which can be controlled more easily. not to put thoughts in people's head | 03:37:07 |
| Winter (she/her) | right
(what do you mean by that last sentence, you don't want to influence anyone's opinion on the matter by saying that?) | 03:38:29 |
| tpw_rules | i guess? it's my personal opinion and thought and i'd appreciate comment from the man himself | 03:39:28 |
| tpw_rules | i think i mixed my metaphors slightly. i don't intend to put words in his mouth | 03:40:00 |
| tpw_rules | there's also this: https://github.com/NixOS/nixpkgs/pull/185078 | 03:42:14 |
| tpw_rules | it's not really fair to characterize python general package updates as "breaking everything all over again" and the notice wouldn't have prevented it. it's just sort of life as being the center of a tangled web of dependencies | 03:43:13 |
| Winter (she/her) | that should be something brought up with the python folks tbh | 03:43:18 |
| Winter (she/her) | exactly | 03:43:20 |
| Winter (she/her) | i'm sure it can be worked around somehow, or things can be put in place | 03:43:31 |
| Winter (she/her) | the python folks are trying to keep up with something so fast moving and prone to breakage, there's only so much they can do without communication | 03:44:00 |
