| 24 Apr 2025 |
 maralorn | Huh, you used callCabal2nix or something similar on 24.11, right? Because the accelerate derivation in nixpkgs indeed does not mention mircolens, formatting or double-conversion. | 14:53:35 |
 Peter Dragos | I did, yes.
My complete overlay was
hs-overlay = final: prev: {
haskell = prev.haskell // {
packageOverrides = hfinal: hprev:
prev.haskell.packageOverrides hfinal hprev // {
parconc-examples = hfinal.callCabal2nix "parconc-examples" ./. { };
accelerate = hfinal.callCabal2nix "accelerate"
(final.fetchFromGitHub {
owner = "AccelerateHS";
repo = "accelerate";
rev = "3f681a5091eddf5a3b97f4cd0de32adc830e1117";
sha256 = "sha256-tCcl7wAls+5cBSrqbxfEAJngbV43OJcLJdaC4qqkBxc=";
}
)
{ };
distributed-process-simplelocalnet =
final.haskell.lib.dontCheck hprev.distributed-process-simplelocalnet;
};
};
parconc-examples = final.haskell.lib.compose.justStaticExecutables final.haskellPackages.parconc-examples;
};
| 14:54:53 |
| Peter Dragos | and the command I'm using to try the build is √ nixpkgs % nix build .#haskellPackages.accelerate --impure, which gives
> Using Parsec parser
> Configuring accelerate-1.3.0.0...
> CallStack (from HasCallStack):
> withMetadata, called at libraries/Cabal/Cabal/src/Distribution/Simple/Utils.hs:368:14 in Cabal-3.10.3.0-inplace:Distribution.Simple.Utils
> Error: Setup: Encountered missing or private dependencies:
> double-conversion >=2.0, formatting >=7.0, microlens >=0.4
| 14:56:16 |
| maralorn | I guess at this point the cleanest solution would be a) get upstream to make a release or b) create a new accelerate-unstable derivation with cabal2nix in nixpkgs and use it to completely replace the existing derivation. cachix does it like that, iirc. | 14:56:47 |
| Peter Dragos | which aligns with what you're finding. So i guess I'd need to do a slightly more involved override for the derivation to add those dependencies (and possibly other fix-ups)? | 14:56:58 |
| maralorn | But otherwise you can probably get by by just adding the dependencies like I described. | 14:57:12 |
| Peter Dragos | great. I'll give it a go, thank you! | 14:58:54 |
| Peter Dragos | Worked great! | 15:30:28 |
|  scm left the room. | 18:41:45 |
| 25 Apr 2025 |
|  relichunter joined the room. | 05:19:55 |
 thirdofmay18081814goya | Anyone have thoughts on nixpkgs default haskell infrastructure vs haskell.nix? | 13:51:55 |
| thirdofmay18081814goya | Is it usecase dependent or does anyone have a preference | 13:52:08 |
 toonn | If you want to upstream things into Nixpkgs, use Nixpkgs infra, otherwise I prefer haskell.nix. | 13:56:28 |
| toonn | It is almost just have a Cabal or Stack setup and a tiny Nix wrapper that hardly changes between projects. | 13:57:12 |
 Teo (he/him) | haskell.nix has pretty bad performance in my experience | 13:57:36 |
| toonn | I use it on a Core2Duo from a decade ago. | 13:58:05 |
| toonn | It's heavier than the Nixpkgs infra though, that's certainly true. But that's because it does so much more. | 13:58:46 |
| thirdofmay18081814goya | hm I see ty for comments | 15:06:24 |
| thirdofmay18081814goya | guess it can't hurt to try both (except for the time expense lol) | 15:06:37 |
| maralorn | The two main advantages I see in haskell.nix are clean derivations for cross-plattform and non-default flags and the possibility to consume a cabal/stack generated build plan. Both of those features I would really want upstreamed into cabal2nix. imo, however if you can get your builds to build without them it is probably not worth the overhead. You are depending on nixpkgs anyway. | 15:16:12 |
| maralorn | My impression is that haskell.nix is a good fit for larger projects/companies where reliably targeting many plattforms is a requirement, it is unrealistic for every team member to be well-versed in the manual dependency resolution dance of nixpkgs, caching is a non-issue because they need their own cache anyway and upstreaming is not a priority. | 15:20:20 |
| maralorn | * My impression is that haskell.nix is a better fit for larger projects/companies where reliably targeting many plattforms is a requirement, it is unrealistic for every team member to be well-versed in the manual dependency resolution dance of nixpkgs, caching is a non-issue because they need their own cache anyway and upstreaming is not a priority. | 15:20:51 |
| maralorn | But I have not actually used haskell.nix a lot. | 15:21:25 |
| toonn | The Nixpkgs infra makes it hard to pick versions of deps. That applies for small projects more than large projects, IMO. | 15:25:28 |
| thirdofmay18081814goya | hm I see | 15:39:30 |
| thirdofmay18081814goya | lots to read and test out heheh, tyvm for comments | 15:39:42 |
|  aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) joined the room. | 15:39:50 |
 shapr | We used haskell.nix when I worked at SimSpace. We had one employee who spent all their time on the nix toolchain things. It was worth it! | 15:41:10 |
| shapr | For my own use, stock nixpkgs is fine 99% of the time. | 15:41:25 |
| 26 Apr 2025 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | I'm trying to build our haskell ecosystem part in Nixpkgs on loongarch64. loongarch64 support of haskell is only available after ghc>=9.12 and llvm>=18. Currently our default is ghc 9.6 and llvm 15. | 03:54:06 |
