| 13 Oct 2024 |
 maralorn | Technically a home manager configuration but you will be able to adapt it. | 18:59:38 |
| maralorn | Ah, and the ghcWithPackages is something I define in another file via ghc.withHoogle (p: ...) | 19:00:18 |
 hellwolf | That indexes packages you have installed? | 19:00:22 |
| maralorn | More or less, yes. | 19:01:23 |
| maralorn | It indexes all packages (and their dependencies) which I passed into that withHoogle call. | 19:01:48 |
| maralorn | Since I also install that ghcWithPackages to my environment I have a hoogle which exactly reflects the provided packages. | 19:02:29 |
| hellwolf | neat | 19:03:33 |
 alexfmpe | I just do
shellFor { withHoogle = True; ...} | 19:09:50 |
| alexfmpe | For project specific hoogle | 19:10:34 |
| alexfmpe | Then
hoogle server --local -p 8080 | 19:10:38 |
| 14 Oct 2024 |
|  m1-s joined the room. | 09:40:24 |
| m1-s | Hi, how can I translate the command cabal test --test-options="--fail-on-focused" into nix? So far I have tried including this flag in the cabal file but this is not supported by cabal. Do I have to override the test phase of the nix derivation? | 09:43:21 |
| m1-s | I guess I can set the env variable HSPEC_OPTIONS for now. Hspec docs say that this is deprecated and will be removed in the future. | 10:20:48 |
 jean-paul. | is there a way to get a callCabal2nix derivation to build all of the tests for a package, in addition to the exes, and include them in the output? | 10:35:14 |
| maralorn | In reply to @m1-s:matrix.org
Hi, how can I translate the command cabal test --test-options="--fail-on-focused" into nix? So far I have tried including this flag in the cabal file but this is not supported by cabal. Do I have to override the test phase of the nix derivation? I think there is a parameter to pass arguments to the test call in our mkDerivation function. | 10:40:54 |
| maralorn | In reply to @jean-paul.:matrix.org
is there a way to get a callCabal2nix derivation to build all of the tests for a package, in addition to the exes, and include them in the output? Well, it already does build them. You probably only need insert a copy statement in the install phase to get them into the output. | 10:41:43 |
| jean-paul. | In reply to @maralorn:maralorn.de
Well, it already does build them. You probably only need insert a copy statement in the install phase to get them into the output. Ah, yes, I guess I might see how that could work. I'll try it out, thanks. | 11:59:15 |
| hellwolf | how should I think about this: I am setting up CI for a project, I'd like to test it against different versions of ghc, but I am facing the choices of testing against the latest hackage set through cabal directly or nixokgs or both. and I didn't even include the stackage... | 16:07:39 |
| maralorn | I actually never had a setup like this. But I would actually do this with plain cabal-install, maybe just installing system deps and ghc with nix. (nix is nice for devshells and deployments but not so nice for enumerating tons of different test setups. Then if you want to test certain library combinations I would sprinkle in version constraints or even a whole stackage snapshot via cabal.project. | 16:18:15 |
| hellwolf | so... then what is the proper purpose of Haskell Nix project, other than using the haskell executable leaf packages? | 16:40:01 |
| maralorn | I mean, there is not really a basis to argue teleologically here. 😄 I think the more relevant question is what it is good at. But our priorities are 1) building Haskell programs for nixos users 2) providing Haskell dev environments via Nix.
May stance is generally that I would always deploy everything with Nix and only test what I deploy, which in implies testing also only happens with Nix.
But if you develop a library for hackage then it makes sense to test it how users will use it, which is probably not with Nix. | 16:58:11 |
| maralorn | * I mean, there is not really a basis to argue teleologically here. 😄 I think the more relevant question is what it is good at. But our priorities are 1) building Haskell programs for nixos users 2) providing Haskell dev environments via Nix.
My stance is generally that I would always deploy everything with Nix and only test what I deploy, which in implies testing also only happens with Nix.
But if you develop a library for hackage then it makes sense to test it how users will use it, which is probably not with Nix. | 16:58:29 |
| maralorn | * I mean, there is not really a basis to argue teleologically here. 😄 I think the more relevant question is what it is good at. But our priorities are 1) building Haskell programs for nixos users 2) providing Haskell dev environments via Nix.
My stance is generally that I would always deploy everything with Nix and I usually only test what I deploy, which implies testing also only happens with Nix.
But if you develop a library for hackage then it makes sense to test it how users will use it, which is probably not with Nix. | 16:59:35 |
| hellwolf | Hehe. That actually makes sense, if I develop in house a Haskell based service, I'd totally use nixpkgs's Haskell packages. That answers my question actually. | 17:00:55 |
| maralorn | I think one big selling point for CI is obviously to use cache.nixos.org. But that only works well for the default ghc version. | 17:00:59 |
| hellwolf | For developing a library, indeed, it's probably asking for troubles since most don't use nix | 17:01:22 |
| hellwolf | * For developing a library that's published to hackage, indeed, it's probably asking for troubles since most don't use nix | 17:01:55 |
| maralorn | But really my short answer is: The primary reason to use Haskell+Nix is if you want deploy or develop on nixos. | 17:03:44 |
| maralorn | I write a lot of bash scripts in Haskell for my nixos systems, with template haskell to ensure presence of called programs at compile time. 😄 | 17:04:46 |
| hellwolf | oh, how does that look like? | 17:05:43 |
