| 20 Apr 2025 |
 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 |
| Tristan Ross | Also, should have a suggestion in case something was removed. | 15:37:46 |
| emily | right, you could have a field for an additional message | 15:37:59 |
| emily | like reason = "known vulnerabilities and unmaintained for years"; suggestion = …; | 15:38:21 |
| emily | rather than manually writing throws and putting dates in comments | 15:38:36 |
| Tristan Ross | I feel like some of the reasons could be defined so it didn't have to be copied and pasted. | 15:39:02 |
| emily | aliases.nix could contain stuff that's meant to stay (the "preserve" stuff) and deprecated.nix could contain stuff on the chopping block | 15:39:04 |
| Tristan Ross | Yeah, aliases could hold things like aliases to latest versions and a sort of legacy-compatibility | 15:39:36 |
| emily | yeah there's mostly like 4 common reasons that get reused a lot :) | 15:39:42 |
| Tristan Ross | I can think unmaintained and vulnerable are the two most common | 15:40:08 |
