Error in v1 Nix support: --add-root flag not supported by nix-shell about cabal HOT 3 OPEN

I'm using v1 with Nix as a workaround for an issue with v2 finding binaries like BNFC, may also affect Alex & Happy

I'd be grateful if you could bump those issues if/when you find them. You are welcome to ping me as well.

from cabal.

This was found in the process of testing https://gist.github.com/ScottFreeCode/9b0ea3e52fa56c93ea8ca14791e55bb4 for whatever that's worth. That gist in turn is relevant to various issues relating to BNFC/Alex/Happy, Cabal+Nix integration, Cabal v2 build, etc. I'm going to be sharing it around to them in the near future, I kinda had a list running but… well, I never put the list all in one place so I'll have to dig them up.

from cabal.

The TL;DR on the Cabal v2 problem is that it doesn't find executables provided by nix-shell.*

Found the issue I opened for it at NixOS/nixpkgs#176887 – that thread also links a lot of GitHub issues, some of which link or are linked to by still more ones, revolving around this problem or related ones about the underlying causes/limitations. The issue reports are scattered across Nixpkgs, IOHK's/IOG's haskell.nix, and Cabal. I can ping all of them if appropriate, or all the Cabal ones that seem to be directly and not merely tangentially related.

Note that unlike the v1- issue, which depends only on using Cabal's --enable-nix/nix: True integration, the v2 issue is only demonstrated by the "+preprocessing" half of the gists, which try to use BNFC, Alex and Happy (I think the issue happens with any of those, and not just with the custom BNFC code generation Setup.hs). The other half of why I put those examples together was to have minimal demonstrations of how to use callCabal2Nix (for which I need to go ask for better documentation, unless it's improved in the past year) and how to automate a BNFC project. (I plan to also share the gist collection on issues where people said "We're using iohk so that we can just write our normal Cabal Haskell project and then have Nix wrap it to provide the dependencies," for example.)

*Or provided by Nix using IOHK's haskell.nix, which I think may be a much more complex wrapper around the same nixpkgs callCabal2Nix that my gists are using directly. Most of the issues where this comes up, concern iohk's haskell.nix; but just using the base callCabal2Nix runs into it and I don't think the issue is really on iohk's end.

from cabal.