| 23 Jun 2023 |
Alyssa Ross | I don't understand what you're saying | 10:37:38 |
Robert Hensing (roberth) | I guess nobody maintains third party packages | 10:37:51 |
Alyssa Ross | What? | 10:37:57 |
Robert Hensing (roberth) | Let's discuss this at a later time | 10:37:58 |
Alyssa Ross | that might be wise | 10:38:13 |
Alyssa Ross | I'll leave a comment on GitHub | 10:38:13 |
Robert Hensing (roberth) | Please don't leave a comment on GitHub | 10:40:16 |
Alyssa Ross | too late | 10:40:42 |
Robert Hensing (roberth) | I'm really sorry about my tone here, but that comment was written with a clear understanding of the problem and I don't want to mudd | 10:40:45 |
Robert Hensing (roberth) | aah ok | 10:40:48 |
Robert Hensing (roberth) | well | 10:40:49 |
Robert Hensing (roberth) | my bad | 10:40:50 |
Alyssa Ross | it'll be okay | 10:41:00 |
Robert Hensing (roberth) | yeah that's an ok comment | 10:41:48 |
Alyssa Ross | :) | 10:41:59 |
Robert Hensing (roberth) | sorry about the drama. I'm actually really busy today and sometimes I feel a bit too responsible for stuff that happens in nixpkgs | 10:43:09 |
Dandellion | In reply to @qyliss:fairydust.space What if we backported the new functions, without a warning? That would maybe work in this case, but as a general policy it can't, it'd be unreasonable to always make secondary functions just to to keep the old name clean for 6 months | 10:43:51 |
Alyssa Ross | I think we all do :) | 10:44:17 |
Robert Hensing (roberth) | For trivial changes we can automate it with lib.isInOldestSupportedRelease (better name suggestions welcome) | 10:44:46 |
Robert Hensing (roberth) | Only for trivial changes though because when we "flip the EOL switch" it creates a bunch of change that should "just work" | 10:45:23 |
Robert Hensing (roberth) | Grossly underdocumented btw, which is another reason to have a policy, as that would be a good place to have or link such docs | 10:46:08 |
Alyssa Ross | yeah, this works for when we want to rename a function, not change its behaviour. | 10:46:23 |
Alyssa Ross | I think this would be a good general policy to adopt for renames | 10:46:39 |
Alyssa Ross | I need to move the functions under rust into lib.systems soon, so that they're available in make-derivation.nix. Previously I would have done it the same way this PR currently proposes, and not even really been aware of the issues that would cause stable. As a result of this discussion, I now know a better way. :) | 10:48:16 |
Robert Hensing (roberth) | btw I think we'll want to make pkgs accessible from make-derivation.nix at some point | 10:49:14 |
Robert Hensing (roberth) | it'd help with things like https://github.com/NixOS/nixpkgs/pull/206728 | 10:49:48 |
Robert Hensing (roberth) | or the inputDerivation thing, which maybe shouldn't be an attribute, but also has a problem that it's unable to create multiple files because it can't have any sort of dependencies because of the lack of pkgs | 10:51:10 |
Alyssa Ross | that'd be nice | 10:51:36 |
Robert Hensing (roberth) | why should make-derivation.nix know about rust though? | 10:51:52 |
Alyssa Ross | Because, unfortunately, it knows about Meson | 10:52:48 |