!RbXGJhHMsnQcNIDFWN:nixos.org

Haskell in Nixpkgs/NixOS

674 Members
For discussions and questions about Haskell with Nix, cabal2nix and haskellPackages in nixpkgs | Current Docs: https://haskell4nix.readthedocs.io/136 Servers

Load older messages


SenderMessageTime
24 Jun 2025
@emilazy:matrix.orgemilyI was going out on a limb because I have no idea what boot library versions are comtemporary any more :)21:04:49
@le:4d2.orglevin yeah, emily was right i think -_-. And the solution is even easier: haskell.packages.ghc810.ghcWithPackages (p: \[haskore\]) seems to build (building right now). Thank you both very much 21:05:16
@emilazy:matrix.orgemilynote that 8.10 is slated for removal AIUI21:05:55
@emilazy:matrix.orgemily so pursuing maralorn's suggestion may be a good use of time 21:06:23
@le:4d2.orglevinit doesn't build, just breaks later lol. then I'll try maralorn solution. Thanks again21:07:42
25 Jun 2025
@alex:tunstall.xyzAlex
In reply to @le:4d2.org

I'm a complete newbie to nix, so please excuse my lack of knowledge:

I'm trying to build the broken package haskore, which is auto-generated by hackage2nix. When building with NIXPKGS\_ALLOW\_BROKEN=1, the build fails with a dependency error (which looks like it comes from cabal, even tough I'm building with nix?):

CallStack (from HasCallStack):
  withMetadata, called at libraries/Cabal/Cabal/src/Distribution/Simple/Utils.hs:368:14 in Cabal-3.10.3.0-cb0e:Distribution.Simple.Utils
Error: Setup: Encountered missing or private dependencies:
bytestring >=0.9 && <0.11, transformers >=0.0.1 && <0.6

Now, further 'investigation' showed, that the packages bytestring and transformers are not in nixpkgs, because the modules they provide are automatically installed when installing ghc.

When trying to tell nix to just not care about those dependencies, I looked into the auto-generated hackage-packages.nix and, indeed, the dependencies for bytestring and transformers are in the buildInputs. But the confusing part is, that many packages have those dependencies, but build perfectly fine, even tough their dependencies, as it seems to me, can't be fulfilled.

Even tough I didn't test it (because I didn't understand how), I believe the error persists in the haskell-updates branch, since the package definition of haskore didn't change.

Can someone explain this to me? Does testHaskellDepends have anything to do with the problem? And do I, with just enough understanding of nix to successfully build my NixOS System, have a chance to fix this issue locally or upstream in about 1-2 days of work? Might someone even volunteer to help me with this?

If you also use markUnbroken (same usage as doJailbreak), you should also be able to avoid the need to NIXPKGS_ALLOW_BROKEN=1.
(Often, combining doJailbreak and markUnbroken is enough to fix Haskell packages marked broken. Occasionally, you may encounter compiler errors doing it and need to actually patch the code.)
03:07:31
@ners:nixos.devners I like to encourage people to use unmarkBroken rather than markUnbroken, as the flag is called broken, not unbroken. 🙃 07:58:18
@le:4d2.orglevin

Success! I had to also disable the Tests since they also do not work (and seem pretty unfixable to me), but with this abomination of a nix-shell command, it builds!

nix-shell -p 'haskellPackages.ghcWithPackages (p: with haskell.lib; [(unmarkBroken (dontCheck (doJailbreak p.haskore)))])'

Is this a solution worth pushing to the repo, or is the usage of doJailbreak and dontCheck too ugly?

11:40:10
@maralorn:maralorn.demaralorn
In reply to @le:4d2.org

Success! I had to also disable the Tests since they also do not work (and seem pretty unfixable to me), but with this abomination of a nix-shell command, it builds!

nix-shell -p 'haskellPackages.ghcWithPackages (p: with haskell.lib; [(unmarkBroken (dontCheck (doJailbreak p.haskore)))])'

Is this a solution worth pushing to the repo, or is the usage of doJailbreak and dontCheck too ugly?

No, that's uptreamable. Imagine how much time you can save the next you without them even realizing.
11:44:29
@maralorn:maralorn.demaralorn
In reply to @ners:nixos.dev
I like to encourage people to use unmarkBroken rather than markUnbroken, as the flag is called broken, not unbroken. 🙃
I have grown quite fond of that little wart.
11:44:53
@lambdatheultimatealias:matrix.orglambdatheultimatealias
In reply to @sternenseemann:systemli.org
lambdatheultimatealias: note that you can't draw any conclusions from nixpkgs about hackage since we regularly apply patches, modify constraints, build flags, test flags etc.
Makes sense. If I follow correctly Hackage just provider the default version and sources which can be overridden depending on stackage and nixpkgs.
11:59:14
@sternenseemann:systemli.orgsterniHackage is just a place for maintainers to upload their packages. Metadata (e.g. constraints) can be edited by maintainers and Hackage trustees after the fact. Hackage makes no statement about which version to use which is the job of the cabal solver or tools like stack(age)12:02:24
@alex:tunstall.xyzAlex
In reply to @ners:nixos.dev
I like to encourage people to use unmarkBroken rather than markUnbroken, as the flag is called broken, not unbroken. 🙃
I didn't even realise there were two functions for it...
12:55:45
@alexfmpe:matrix.orgalexfmpeAren't there 4?16:19:31
@alexfmpe:matrix.orgalexfmpeTwo names each for turning it on and ofd16:19:42
@alexfmpe:matrix.orgalexfmpe* Two names each for turning it on and off16:19:59
@maralorn:maralorn.demaralorn
In reply to @alexfmpe:matrix.org
Aren't there 4?
I think in that sense there are 3. Because markBroken cannot not have the un in different places
16:41:06
@alexfmpe:matrix.orgalexfmpeHuh I assumed there was unmarkUnbroken16:43:27
@alexfmpe:matrix.orgalexfmpeCan't we just deprecate one of them and end this?16:43:42
@maralorn:maralorn.demaralornWe totally could. But I like them too much to do it myself. 😂16:46:56
@maralorn:maralorn.demaralornWhat the heck is the correct way to run doctests in a nixpkgs package?21:20:33
@maralorn:maralorn.demaralorncabal repl --with-compiler=doctest does not work because the doctest does not have the same pkg db than the ghc used by cabal.21:21:10
@sternenseemann:systemli.orgsternicabal exec -- cabal repl --with-compiler=doctest maybes22:16:44
@sternenseemann:systemli.orgsterni* cabal exec -- cabal repl --with-compiler=doctest maybe?22:16:46
@maralorn:maralorn.demaralorn

Still the same problem:

Configuring library for status-script-0.1.0.0...
Loaded package environment from /home/maralorn/git/config/packages/status-script/dist-newstyle/tmp/environment.-175358/.ghc.environment.x86_64-linux-9.8.4
<command line>: cannot satisfy -package-id aeson-2.2.3.0-2mnLs4rnok4A0ksXaTX6dm

and I am relatively certain that is because cabal-install does use a different ghc pkg db.

22:34:42
@maralorn:maralorn.demaralorn *

Still the same problem:

Configuring library for status-script-0.1.0.0...
Loaded package environment from /home/maralorn/git/config/packages/status-script/dist-newstyle/tmp/environment.-175358/.ghc.environment.x86_64-linux-9.8.4
<command line>: cannot satisfy -package-id aeson-2.2.3.0-2mnLs4rnok4A0ksXaTX6dm

and I am relatively certain that is because cabal-install does use a different ghc pkg db than doctest.

22:34:46
@maralorn:maralorn.demaralornSo this seems to me that we should maybe patch doctest so that it picks up the package db from the ghc.withPackages it is used from?22:35:25
26 Jun 2025
@sternenseemann:systemli.orgsterniah yes I remember https://github.com/haskell/cabal/issues/7792#issuecomment-212430424421:25:04
28 Jun 2025
@peterbecich:matrix.orgPeter Becich

On haskell-updates branch, ./maintainers/scripts/haskell/regenerate-hackage-packages.sh produces

...
hackage2nix: user error (cannot parse cabal file /nix/store/kmz1d73l5k1nhv5269dl5i68yjwlbcir-unpacked-cabal-hashes/pms-application-service/0.0.3.0/pms-application-service.cabal)
hackage2nix: thread blocked indefinitely in an MVar operation

Does anyone else see this or is it local to me?

20:22:52
29 Jun 2025
@b:chreekat.netchreekat
In reply to @peterbecich:matrix.org

On haskell-updates branch, ./maintainers/scripts/haskell/regenerate-hackage-packages.sh produces

...
hackage2nix: user error (cannot parse cabal file /nix/store/kmz1d73l5k1nhv5269dl5i68yjwlbcir-unpacked-cabal-hashes/pms-application-service/0.0.3.0/pms-application-service.cabal)
hackage2nix: thread blocked indefinitely in an MVar operation

Does anyone else see this or is it local to me?

I think the real error is getting swallowed somewhere. I know from fixing Stackage recently that that package uses a newer version of Cabal file format, so hackage2nix (or whatever underlying tool) probably also needs to be built with an updated version of the cabal library
07:11:34

Show newer messages


Back to Room ListRoom Version: 6