| 17 Oct 2024 |
 sterni | is it just me or is https://github.com/NixOS/nixpkgs/pull/346720 no longer updating? There are newer commits on haskell-updates that don't show up for me… | 11:36:42 |
 maralorn | Nope, can reproduce. | 11:40:51 |
| maralorn | I have observed stale PRs at least once more recently. | 11:42:41 |
| maralorn | * I have observed stale PR views on GitHub at least once more recently. | 11:42:51 |
| maralorn | Curious what happens if you merge it. 😄 | 11:43:01 |
| sterni | It has updated now | 11:54:04 |
| sterni | I think the hook when you push misfired since the two commits I pushed earlier now show up as having been added yesterday | 11:54:41 |
|  Mic92 changed their display name from Mic3000 🌋 to Mic92. | 12:22:31 |
| maralorn | In reply to @maralorn:maralorn.de
btw. just watching the Haskell talks from ICFP and it’s kinda weird to see so many people mentioning in passing that they rely on Nix for some crazy stuff without ever having any interactions with them. To pick on that. What do they do if stuff breaks? Do they just maintain everything in-house? Do some of our regular contributors work for them and I just can’t map them? | 13:07:59 |
| maralorn | In reply to @maralorn:maralorn.de
btw. just watching the Haskell talks from ICFP and it’s kinda weird to see so many people mentioning in passing that they rely on Nix for some crazy stuff without ever having any interactions with them. * To pick on that. What do they do if stuff breaks? Do they just maintain everything in-house? Do some of our regular contributors work for them and I just can’t map them? Do they use haskell.nix? | 13:08:06 |
| maralorn | * To pick up on that. What do they do if stuff breaks? Do they just maintain everything in-house? Do some of our regular contributors work for them and I just can’t map them? Do they use haskell.nix? | 13:08:21 |
 emily | I think usually the answer to these things is "deal with it" or "hack around it". | 13:08:31 |
| emily | the people you hear from organically are the weird subset who will actively reach out. most people just kind of accept it when software is broken | 13:09:02 |
| maralorn | I mean it’s one thing when people don’t upstream fixes, that’s okay. I can’t expect anyone to do free work for us. But the idea creeps me out that we have tons of enterprise users who all stack workaround on workaround without telling us there is a problem. | 13:10:06 |
| maralorn | I think I’m gonna reach out to some people to hear how they are doing with nix. | 13:10:59 |
 toonn | The worst part is that if they pitched in at all it could reduce pains for everyone involved. | 13:12:12 |
| emily | they are not necessarily even using upstream Nixpkgs | 13:12:49 |
 teo (they/he) | I don't know about the Mercury folks, but both Haskell companies I've worked at use haskell.nix. I feel like it's the go-to one in industry | 13:14:48 |
| maralorn | I mean, I am just curious. I don’t know if this is actually what is happening. | 13:27:53 |
 Alex | In reply to @teoc:matrix.org
I don't know about the Mercury folks, but both Haskell companies I've worked at use haskell.nix. I feel like it's the go-to one in industry This isn't the case at my workplace (we use the Nixpkgs system, mostly callCabal2nix).
haskell.nix is nice when you have another build solver (e.g. Stack) to tell you which package versions to use, but when you don't the versions selected by Nixpkgs usually Just Work™, as one should expect of something that tracks Stackage. | 13:48:23 |
| sterni | none of the two haskell companies I've worked at have used haskell.nix ¯_(ツ)_/¯ | 13:53:23 |
| teo (they/he) | Fair enough maybe I'm an outlier :) | 14:06:12 |
| toonn | Alex: So you don't keep Cabal bounds? | 14:07:35 |
| Alex | No. The things we write are internal-only, so there's nearly 0 chance they get used without Nix. | 14:08:31 |
| toonn | So that's what forces you into the Stackage model. I assumed keeping bounds was common. | 14:10:07 |
| Alex | We're not too concerned about versions as long as we're relatively up-to-date and we don't lose much time to build failures. | 14:11:14 |
| maralorn | In reply to @alex:tunstall.xyz
No. The things we write are internal-only, so there's nearly 0 chance they get used without Nix. Totally on board with that. nix-output-monitor e.g. has no cabal bounds. The only goal is that it builds in current nixos-unstable the rest doesn’t matter. | 14:21:28 |
| maralorn | otoh, as soon as you publish something on hackage good bound hygiene is mandatory. | 14:22:01 |
| toonn | I've found it's convenient to be able to exclude buggy versions of dependencies or hold off on an API change in a dependency. | 14:51:15 |
| maralorn | Yeah, of course, but then you probably need some kind of override anyway. | 15:25:46 |
