cabal inside nix shell seems confused about build-tools such as happy

[Ptival]

To reproduce, you can try to use this repository (it's fairly small)

Ptival/language-ocaml@0df752c

To try and reproduce (hopefully it's not just my machine):

$ nix-shell
# wait...
[nix-shell] $ cabal build language-ocaml

If it behaves like me, you will get the following message:

Warning: No remote package servers have been specified. Usually you would have
one specified in the config file.
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: language-ocaml-0.2.2 (user goal)
[__1] unknown package: language-ocaml:happy:exe.happy (dependency of
language-ocaml)
[__1] fail (backjumping, conflict set: language-ocaml,
language-ocaml:happy:exe.happy)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: language-ocaml,
language-ocaml:happy:exe.happy

I've been able to have happy, the executable, in path, but still, when trying to build the library, cabal seems to want some target <lib>:happy:exe.happy and does not know what it is.

Also, I don't know if it's just me, but in the nix-shell, when I run cabal update, I get:

$ cabal update
newParallelJobControl: not a sensible number of jobs: 0
CallStack (from HasCallStack):
  error, called at ./Distribution/Client/JobControl.hs:101:3 in main:Distribution.Client.JobControl

[michaelpj]

At a wild guess you want build-tool-depends instead of build-tools, and you need the proper component syntax, e.g. happy:happy. I think more recent cabals interpret build-tools differently now, so your issue may just be using a newer cabal than you're used to.

As for the update issue, that's because you have exactDeps=true, so we override CABAL_CONFIG, and presumably we don't provide a value for jobs, which makes cabal explode. It would be nice if it picked a good default, but 🤷 I guess we could stuff a value for that in our generated config file.

[michaelpj]

I tried using build-tool-depends and that didn't help. That seems very odd: we have plenty of packages that use happy just fine, so I'm not sure what's up here.

[Ptival]

Great, I can confirm that, by removing exactDeps = true, I can build my project within the nix shell.

cabal ended up building alex/happy within the shell, but it was able to do so.

I'm not sure I understand everything, but it seems that:

• adding alex/happy to the tools section makes the executables available, but they are not registered in cabal,
• exactDeps set to true makes cabal unable to figure out what they should be.

What I'm unclear is whether happy should have been registered in cabal in the nix shell due to its presence in the build-tools section.
At least I am no longer stuck, thanks for the help!

[michaelpj]

Seems like a bug! In particular, I think that's the same cabal config as we use in the main derivation, so it's odd that it would work there and not here.

[Ptival]

Warning for direnv and/or lorri users!

I just wasted a shameful amount of time debugging why, for a certain project, it would build just fine on one of my machines, and fail to build on another machine.

Eventually I tried cabal update on both machines, and it worked on the working machine, and errored with the "not a sensible number of jobs" error on the failing machine.

It turns out that my last successful build was for a shell that had exactDeps = true, so from now on, direnv would load the environment with CABAL_CONFIG overridden whenever I entered that directory. So, even though the current derivation did not have exactDeps = true, it behaved as if it did!

So, be careful to either direnv disallow when switching from exactDeps = true to not, or to clear the CABAL_CONFIG environment variable if you encounter issues!

[purefn]

I'm encountering a similar issue with plutus-starter. I wanted to use a nix-shell for working on a smart contract, and was hoping it would mean I didn't have to build too much with cabal. But it doesn't have exactDeps=true set, so I tried setting it. Starting the nix shell works fine, but when I try to build with cabal I encounter this same issue with plutus-core

Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: plutus-core-0.1.0.0 (user goal)
[__1] unknown package: plutus-core:happy:exe.happy (dependency of plutus-core)
[__1] fail (backjumping, conflict set: plutus-core,
plutus-core:happy:exe.happy)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: plutus-core,
plutus-core:happy:exe.happy

And because plutus-core is such a core library, I end up needing to build lots of things with cabal when exactDeps = false. Any advice?

[discosultan]

Ran into the same problem with plutus-starter. @purefn, did you find a fix/workaround?

[purefn]

Sadly, nothing other than setting exactDeps = true; and letting cabal rebuild tons of things. I'm not sure it is solvable from haskell.nix. I believe it would need to be fixed by changing cabal to allow build tool dependencies to be found some way other than through the cabal build plan.

[ScottFreeCode]

This seems like it may be a more general problem with Cabal and the build-tool-depends replacement for build-tools: haskell/cabal#7197

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[michaelpj]

Unsure if this is in fact solved?

[purefn]

@michaelpj , I don't believe it is fixed. I ran into this again recently with thyme and cpphs.

[angerman]

@purefn if we pass --with-hsc2hs=... --with-happy` to cabal/SETUP_HS, does that work? E.g. if we are being explicit about the tools we want to use?

[ScottFreeCode]

Not 100% certain if everyone encountering this is hitting the "nix shell + cabal v2" version of this issue, but for the sake of anyone who is:

I have a straightforward reproduction without iohk's/iog's haskell.nix, here: https://gist.github.com/ScottFreeCode/c1adb5681c5b61c61373615f63a4a7d2

I've collected GitHub issues relating to this problem here: https://gist.github.com/ScottFreeCode/ef9f254e2dd91544bba4a068852fc81f