| 20 Apr 2025 |
 Tristan Ross | If anyone else wants to look at this before it's merged, please do. https://github.com/NixOS/nixpkgs/pull/394797 | 04:23:42 |
| Tristan Ross | I'm going to work on what this is: https://github.com/NixOS/nixpkgs/pull/375435#discussion_r1927770569
We'll have a new nixpkgs config option called allowVariants and we'll have pkgs/top-level/variants.nix. This enables the nixpkgs variants like pkgsLLVM, pkgsMusl, etc. | 15:12:20 |
| Tristan Ross | https://github.com/NixOS/nixpkgs/pull/400351 we have the variants in this pr | 15:27:58 |
 emily | how does that interact with https://github.com/NixOS/nixpkgs/pull/380342? | 15:29:27 |
| emily | ah, it's just making them alias-ish | 15:29:52 |
| Tristan Ross | Yeah, it's just alias-like | 15:30:01 |
| emily | wouldn't it be better to just put them behind config.allowAliases like other convenience things? | 15:30:04 |
| Tristan Ross | Well, they're kinda different imo. | 15:30:21 |
| Tristan Ross | An alias is something more like llvmPackages_latest being a shorthand for the latest LLVM version, it's an alias lol | 15:30:52 |
| Tristan Ross | But these are variants of nixpkgs | 15:31:01 |
| Tristan Ross | Some of these might be needed for some things to function, I want to move more from stage into variants but I didn't want to break anything. | 15:32:18 |
 aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | I had an issue with allowAliases | 15:33:12 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | Can we tell users that "the variable is part of aliases so it's not allowed to use with config.allowAliases = false" instead of "the variable doesn't exist" | 15:33:40 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | But it would probably be hard | 15:33:54 |
| Tristan Ross | I think we'd have to determine what is added in from aliases | 15:34:08 |
| Tristan Ross | But it actually wouldn't be too impossible. | 15:34:15 |
| emily | if we had an actually structured alias system, yeah | 15:34:17 |
| emily | but we don't | 15:34:19 |
| emily | we should, because we should warn for the deprecated kind of aliases | 15:34:29 |
| emily | aliases.nix is too much manual work and doesn't inform users of deprecations | 15:34:45 |
| Tristan Ross | Imo, we should have a deprecations.nix or removed.nix. Aliases is too broad. | 15:35:18 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | Yeah, but how do we handle this as a general case, and also for config.allowVariants | 15:35:24 |
| emily | also the date-based system is silly, since stuff gets merged later than it gets written | 15:35:24 |
| emily | it should be based on releases instead | 15:35:27 |
| emily | splitting out deprecations and preserved aliases makes sense. I think we don't need to separate out removed things | 15:36:15 |
| emily | it could just look like deprecatedPkg = { release = "25.05"; alias = newName; }; or deprecatedPkg = { release = "25.05"; }; for a removed thing | 15:36:56 |
| emily | which would also make automating dropping stuff easier, there's currently a sorta gross script that doesn't handle all the cases | 15:37:08 |
| Tristan Ross | Yeah, something which automagically handles deprecations is better | 15:37:33 |
| emily | other scopes are where it gets awkward | 15:37:36 |
| emily | probably we'd want a thing to process these in lib so that it could be reused across the tree | 15:37:45 |
