| 21 Oct 2024 |
 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 |
| Fabián Heredia | about 2-3 releases ago | 17:03:00 |
| emily | right | 17:03:12 |
| Fabián Heredia | and previous flow was to directly throw on aliases that were going to be removed / had a planned removal. | 17:03:41 |
| emily | I was thinking we could just lib.mapAttrs (k: v: lib.warn "hey man stop using ${k}" v) the aliases.nix attrset | 17:03:42 |
| emily | I don't know if that's crazy or not. | 17:03:54 |
| emily | maybe even do a tryEval dance so it'll only warn on things that aren't already throws | 17:04:14 |
| Fabián Heredia | But not all aliases there are intended to be removed, there is a top level comment on the syntax of comments to avoid auto move to throw/auto removal from the prune script | 17:04:29 |
| Fabián Heredia | # A script to convert old aliases to throws and remove old
# throws can be found in './maintainers/scripts/remove-old-aliases.py'
| 17:05:15 |
| Fabián Heredia | # Add 'preserve, reason: reason why' after the date if the alias should not be removed.
# Try to keep them to a minimum.
| 17:05:39 |
| emily | well, we could separate out the ones not to be removed into another section. | 17:05:47 |
