21 Oct 2024 |
emily | seems like that would make aliases.nix the most stable interface in the repository | 11:22:42 |
emily | I can't imagine any reason to attach dates other than to remove later though | 11:23:10 |
emily | seems to me like allowAliases is the warning | 11:23:36 |
hexa | aliases should warn immediately imo 😛 | 11:23:38 |
hexa | yeah, kinda | 11:23:42 |
hexa | but I think people want eval traces | 11:23:51 |
emily | til remove-old-aliases.py | 11:24:14 |
emily | I feel like the fact that that script exists and that it was in the release process notes indicates a consensus that extends beyond one person's objections. | 11:24:47 |
emily | In reply to @hexa:lossy.network aliases should warn immediately imo 😛 (is there any reason we don't do that other than nobody made the infrastructure for it? seems like it would be a "simple" mapAttrs ) | 11:27:38 |
hexa | feel free to give it a shot | 11:27:59 |
Sandro 🐧 | * Debians poor depreciation processes hitting again | 12:10:48 |
Sandro 🐧 | In reply to @hexa:lossy.network says distro who has an ever growing aliases file, no proper deprecation cycle and other failings Those things are minor compared to Debian and you don't notice mid upgrade in an unstable state that some package is now missing. | 12:12:12 |
Sandro 🐧 | In reply to @emilazy:matrix.org so the idea is that we have to go alias → alias with warning → throw → removal? alias and alias with warning are the same thing, aren't they? | 12:14:13 |
Sandro 🐧 | and between the other steps I think we had something like one release cycle | 12:14:24 |
Alyssa Ross | no warning means nobody gets a chance to notice | 12:15:16 |
emily | In reply to @sandro:supersandro.de alias and alias with warning are the same thing, aren't they? howso? | 12:15:18 |
emily | In reply to @qyliss:fairydust.space no warning means nobody gets a chance to notice I think allowAliases = false is meant to serve the purpose of giving notice to those it matters for | 12:16:18 |
emily | (though whether it is effective at that, idk) | 12:16:23 |
Sandro 🐧 | In reply to @qyliss:fairydust.space no warning means nobody gets a chance to notice I may be confusing this with the module system which warns immediately. We should add that 🤔 | 12:16:34 |
Sandro 🐧 | like why don't we have that | 12:16:51 |
Alyssa Ross | Yeah | 12:16:53 |
emily | https://github.com/NixOS/nixpkgs/issues/195702 has some discussion about the difficulties about making aliases warn. | 12:17:18 |
emily | I don't entirely understand the difficulties though. | 12:17:23 |
Sandro 🐧 | In reply to @emilazy:matrix.org I think allowAliases = false is meant to serve the purpose of giving notice to those it matters for well, nay. It treats it like it is already gone and ignores the entire aliases file | 12:17:34 |
Alyssa Ross | In reply to @emilazy:matrix.org I think allowAliases = false is meant to serve the purpose of giving notice to those it matters for I don't think that's the purpose of allowAliases. I think allowAliases is there for OfBorg, and to make it possible to process whole attrsets without encountering a bunch of throws. | 12:17:47 |
emily | In reply to @sandro:supersandro.de well, nay. It treats it like it is already gone and ignores the entire aliases file yes, which means if you test in CI with allowAliases = false you get early warning of upcoming breaking changes without disrupting users | 12:17:55 |
emily | which is actually better than unconditional warnings | 12:18:00 |
Sandro 🐧 | yeah, warning as it breaks, not as a literal warning. I've been using that since forever to never use aliases. | 12:18:51 |
Sandro 🐧 | we just need to add a warn https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/aliases.nix#L55 here, right? | 12:19:24 |
Alyssa Ross | In reply to @emilazy:matrix.org yes, which means if you test in CI with allowAliases = false you get early warning of upcoming breaking changes without disrupting users Right but people are not generally testing their NixOS configurations in CI | 12:19:49 |