| 17 Oct 2024 |
 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 |
| sterni | In reply to @maralorn:maralorn.de
otoh, as soon as you publish something on hackage good bound hygiene is mandatory. you can set x-curated to exclude yourself from curation then you're neither obliged to maintain bounds nor follow PVP | 15:41:11 |
| sterni | not sure what that setting actually influences though… | 15:41:19 |
| sterni | I think bound management can become easy if someone sits down and writes a little bit of tooling, basically you just need to get notified about releases in your dependencies and then be provided with a install plan to easily test the new possibility | 15:42:38 |
| sterni | this could probably even be automated completely | 15:42:50 |
| maralorn | Well I didn't mean there is a rule, just that it is helpful to consumers. | 15:43:41 |
| maralorn | I mean nomeata automated a significant chunk of that with the cabal bounds stuff. | 15:44:53 |
| toonn | Even without tooling it's often pretty easy in my experience. | 15:52:24 |
| toonn | Once the API starts changing it's probably not worth perserving buildability with older versions on newer releases anyway. | 15:52:50 |
