| 14 Jan 2025 |
 Niklas Korz | * rec packages are hard to overrideAttrs, so I wonder what problem the finalAttrs pattern has? | 10:55:41 |
| Niklas Korz | the way things have been moving recently I see stdenv.mkDerivation + hooks + finalAttrs to become the norm, so if that would be problematic down the line I think now would be the time to raise awareness of why this would be a bad idea | 10:57:11 |
 l1npengtul | I've been using let...in for all my new derivations, is that bad? | 11:00:12 |
| Niklas Korz | no, let in is fine! | 11:03:30 |
| Niklas Korz | it's just a wide-scoped with ... that can cause issues | 11:03:53 |
| l1npengtul | oh thats nice to hear
| 11:04:31 |
 toonn | `let in` is also an alternative to rec/finalAttrs, with yet different trade-offs. | 11:05:34 |
| toonn | I don't remember where the write up of the problems with each of the three alternatives is. | 11:07:06 |
 @sigmasquadron:matrix.org | In reply to @niklaskorz:korz.dev
rec packages are hard to overrideAttrs, so I wonder what problem the finalAttrs pattern has? finalAttrs's only drawback is that it's only available on the default stdenv for now. | 11:11:29 |
| Niklas Korz | In reply to @sigmasquadron:matrix.org
finalAttrs's only drawback is that it's only available on the default stdenv for now. which is why I also mentioned there seems to be more push towards hooks instead of custom build functions | 11:15:17 |
| Niklas Korz | obviously I will not recommend someone to exchange a custom builder with rec for hook + finalAttrs in a review, but I see no reason not to use finalAttrs when a PR already uses stdenv.mkDerivation | 11:16:11 |
| Niklas Korz | * obviously I will not recommend someone to exchange a custom builder with rec for hook + finalAttrs in a review, but I see no reason not to use finalAttrs when a PR already uses stdenv.mkDerivation rec | 11:16:16 |
 Grimmauld | In reply to @sigmasquadron:matrix.org
finalAttrs's only drawback is that it's only available on the default stdenv for now. Isn't it also available for stdenvNoCC ? | 11:17:45 |
| Niklas Korz | yeah, but not in buildRustPackage e.g. (although there is an open PR) | 11:18:16 |
| toonn | If no one has complained about not being able to override a package then rec shouldn't be replaced at all. Keep it for a treewide or something. | 11:18:26 |
| toonn | New expressions being the exception. | 11:18:38 |
| @sigmasquadron:matrix.org | In reply to @grimmauld:grimmauld.de
Isn't it also available for stdenvNoCC ? By "non-default stdenv", I implied the builders in build-support | 11:18:43 |
| Niklas Korz | In reply to @toonn:matrix.org
If no one has complained about not being able to override a package then rec shouldn't be replaced at all. Keep it for a treewide or something. fair enough, on that I can agree | 11:18:52 |
| toonn | Nixpkgs would benefit a lot from ratcheting lints. | 11:18:55 |
| Grimmauld | In reply to @toonn:matrix.org
Nixpkgs would benefit a lot from ratcheting lints. Blocking additions of with lib;, rec and similar? Might make sense, but I feel the ratchet database keeping track of occurrence count would end up a merge conflict hell | 11:27:52 |
 @lily:lily.flowers | In reply to @grimmauld:grimmauld.de
Blocking additions of with lib;, rec and similar? Might make sense, but I feel the ratchet database keeping track of occurrence count would end up a merge conflict hell (nixpkgs already implements several ratchet lints, so i'm not sure what you're saying the problem with ratcheting is here?) | 11:29:54 |
| Grimmauld | In reply to @lily:lily.flowers
(nixpkgs already implements several ratchet lints, so i'm not sure what you're saying the problem with ratcheting is here?) Huh. Didn't know that. How is the count being tracked and updated? | 11:33:15 |
| @lily:lily.flowers | In reply to @grimmauld:grimmauld.de
Huh. Didn't know that. How is the count being tracked and updated? what count? | 11:33:41 |
| Grimmauld | In reply to @lily:lily.flowers
what count? Don't you need to store a count of how many "disallowed" patterns were in the code before a change to determine whether an addition is adding one of those disallowed patterns? | 11:35:42 |
 K900 | No, you just run the lint twice | 11:36:10 |
| Niklas Korz | sometimes it's the simple solutions that work best😄 | 11:36:40 |
| @lily:lily.flowers | In reply to @grimmauld:grimmauld.de
Don't you need to store a count of how many "disallowed" patterns were in the code before a change to determine whether an addition is adding one of those disallowed patterns? it's ratched per-file and yeah just run before to determine whether it's already ratcheted and if an after lint run needs to be enforced | 11:37:45 |
| Grimmauld | In reply to @k900:0upti.me
No, you just run the lint twice Ah fair. Yeah that works. Damn it, no need to be smart I guess XD | 11:37:44 |
| @lily:lily.flowers | * it's ratched per-file and yeah just run before to determine whether it's already ratcheted which determines if an after lint run needs to be enforced | 11:38:06 |
| @lily:lily.flowers | * it's ratched per-file and yeah just run before-change to determine whether it's already ratcheted which determines if an after-change lint run needs to be enforced | 11:38:22 |
