| 21 Oct 2024 |
 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 |
| emily | I don't know if NixOS configurations are really the most relevant case here? since it's quite easy to just react to "hey, this alias X is now Y, please migrate to that" on updates there. not that it'd be nice to be able to be more proactive but the quoted justification for this kind of extended compatibility cycle I've seen has always been third-party modules that want to support multiple Nixpkgs versions at once, etc. | 12:20:59 |
| Sandro 🐧 | third party can always check lib.version and do things conditional based on that | 12:22:04 |
| Sandro 🐧 | we can't do reflection, so we probably should adapt the python script | 12:41:31 |
 Fabián Heredia | In reply to @emilazy:matrix.org
so the idea is that we have to go alias → alias with warning → throw → removal? alias with warn (now that warn exists) -> throw -> removal | 17:02:00 |
| emily | hm, what do you mean "now that warn exists"? | 17:02:15 |
| Fabián Heredia | skipping the first one | 17:02:16 |
| Fabián Heredia | of only alias without warn | 17:02:22 |
| Fabián Heredia | There was a time when aliases couldn't warn not too long ago if I recall correctly | 17:02:50 |
