Haskell in Nixpkgs/NixOS | 729 Members | |
| For discussions and questions about Haskell with Nix, cabal2nix and haskellPackages in nixpkgs | Current Docs: https://haskell4nix.readthedocs.io/ | More Nix: #community:nixos.org | More Haskell: #haskell-space:matrix.org | 146 Servers |
| Sender | Message | Time |
|---|---|---|
| 4 Nov 2024 | ||
| We somehow need to converge what cabal does and what nix does in terms of build targets. For hoogle I would highly recommend using the unoverriden hoogle. That might currently not be super convenient to do in nixpkgs, but its definitely the right solution. For tests it depends on what we want. But I see no reason why it would be hard to disable tests for dependencies but enable all tests and binaries for the current repo. | 11:55:30 | |
| * We somehow need to converge what cabal does and what nix does in terms of build targets. For hoogle I would highly recommend using the unoverriden hoogle. That might currently not be super convenient to do in nixpkgs, but its definitely the right solution. For tests it depends on what we want. But I see no reason why it would be hard to disable tests for dependencies but enable all tests and binaries for the current repo. I actually think that is already the default with your approach. | 11:55:45 | |
In reply to @maralorn:maralorn.de"unoverriden hoogle" like adding hoogle to the list of cabal dependencies? or use the one from nixpkgs? | 11:57:17 | |
| as for tests, I can see that cabal added quickcheck and stuff like that to the freeze file, so it must be ok for the repo, I have to test it though | 11:58:06 | |
| That’s what I had expected. | 11:59:56 | |
| I mean use the one from nixpkgs. There is no sensible requirement to recompile hoogle with the library versions you picked. | 12:00:33 | |
| ok then, in that case if I want to use the same package set, it will conflict. would it be possible to use a different packageset or the default one for hoogle then? | 12:02:29 | |
| so beside the inclusion of flags, and cleanups what would be the next step folks? | 12:03:08 | |
| idk, if your project works I’d say you ship it. 😄 | 12:04:28 | |
| But I am happy to review the stuff in more detail, give feedback and brainstorm next steps. | 12:05:01 | |
| cool, I like that, I'll clean up the code, and ping you. and hopefully make it available for others to use | 12:10:25 | |
| I tried to use a newer GHC (9.10) to test this solution, and I made sure that the freeze file is generated with the same compiler version (9.10) but I run into a conflict with the base version. base package is shipped with the compiler right? | 13:02:38 | |
In reply to @lxsameer:matrix.orgeverywhere the freeze file contains flags, yes. I assume the default is implied otherwise | 13:48:06 | |
| it won’t if you just add it to PATH for a development environment | 13:48:56 | |
| some libs depend on QuickCheck so that they can expose non orphan Arbitrary instances | 13:49:49 | |
In reply to @lxsameer:matrix.orgyes | 13:50:10 | |
and non reinstallable because it exposes some GHC modules | 13:50:38 | |
| hmmm so what would be the solution here? here is an example of the error:
| 13:52:05 | |
| cool | 13:53:10 | |
| Is primitive in your lock file? | 15:39:26 | |
| And is this using the primitive version from your lock file? | 15:43:26 | |
| oh flake.lock? I forgot about that one | 16:06:03 | |
| let me investigate | 16:06:11 | |
In reply to @maralorn:maralorn.deremoved the flake.lock, still the same issue. primitive is in the freeze file with the correct version | 16:10:47 | |
| I just noticed that even though I used cabal-install from ghc910 packageset, the ghc on the path is 9.6 | 16:17:13 | |
doesn't look like it | 16:28:21 | |
| lxsameer: is primitive 0.9 or 0.8 in your freeze file? | 16:29:20 | |
In reply to @sternenseemann:systemli.orgfor the time I was generating the freeze file | 16:30:05 | |
| I regenerated the freeze file and it is 0.9.0.0 now, buuuuut | 16:30:26 | |
| okay, yeah that won't work | 16:30:30 | |