splitFileName and minusFileName Variable not in scope causes builds to fail

[istathar]

Describe the bug
Autogenerated Paths_ modules are failing to compile

../../../bazel-out/k8-fastbuild/bin/external/stackage/regex-base-0.94.0.2/regex-base-0.94.0.2/build/autogen/Paths_regex_base.hs:48:17: error:
    Variable not in scope: splitFileName :: FilePath -> (a, b0)
   |
48 |   let (dir,_) = splitFileName exePath
   |                 ^^^^^^^^^^^^^

../../../bazel-out/k8-fastbuild/bin/external/stackage/regex-base-0.94.0.2/regex-base-0.94.0.2/build/autogen/Paths_regex_base.hs:49:16: error:
    Variable not in scope: minusFileName :: t0 -> String -> String
   |
49 |   return ((dir `minusFileName` "bin") `joinFileName` dirRel)

To Reproduce

This started happening when we tried to upgrade from a nightly snapshot from mid July to lts-20.1. We know we had to downgrade to GHC 9.2.4, that doesn't appear to be a problem. We've upgraded NixPkgs, Bazel, rules_haskell, anything we can think of, but the problem keeps reoccuring. It's not just regex-base as above; it's also happening with transformers-compat, unliftio-core, ...

A few months ago this problem cropped up in relation to "relocatable", #1749 (comment). The fix there (to not enable relocatable) was reverted. I've since tried that patch again, but still no luck; disabling relocatable makes the bild fail much earlier.

I tried latest version of rules_haskell from Git (no difference), tried upgrading Cabal (couldn't get that to build),

Expected behavior

Be delighted if we could keep using Bazel to build the Haskell code, but unsure what to try next. Any suggestions would be appreciated!

Environment

• Nix on Linux
• Bazel version: 5.2.0
• Version of the rules: both 0.15 and master

[avdv]

Hi @istathar, thank you for the bug report!

Unfortunately, this is a known issue and we cannot really do anything about it. Specifically, it is a regression in Cabal introduced in 3.6.0 which was only recently fixed in haskell/cabal#8220

Once there is a new Cabal release, we should look into how we can support using that with existing GHC bindists.

[GuillaumeGen]

This is indeed an issue with cabal, that has been identified a few months ago and for which a pull request has been issued (and merged, but sadly not included in a released version yet).

The only workaroud we can offer currently is to do as suggested in https://github.com/tweag/gazelle_haskell_modules#using-ghc-version-92 ie use a forked version of cabal (42f04c3f639f10dc3c7981a0c663bfe08ad833cb of github.com/tweag/cabal is cabal 3.6.3.0 with the fix of haskell/cabal#8220) and explicitly declare that every package which uses a Paths_ module depends of this patched version of Cabal.

This is definitely bad UX, we are aware of it, but as stated by Claudio, there is not much more we can do.

[anton-k]

I wonder why do we need cabal in the first place?
If we don't write the cabal files. Isn't it possible to use GHC directly for builds?

[anton-k]

I've hit this bug too :(

mac os, bazel 5.2.0, ghc 9.2.4

[anton-k]

So far it seems to be the weird mixture of artefacts from bazel, cabal, stack and even nix if you need it.
The head goes round.

I wish that it was self contained.

[aherrmann]

I wonder why do we need cabal in the first place?
If we don't write the cabal files. Isn't it possible to use GHC directly for builds?

Cabal is used for third-party dependencies imported from Stackage (or Hackage) via Stack and built via Cabal. You can read more about the motivation behind this approach in this blog post.

I've hit this bug too :(

Does the workaround mentioned by @GuillaumeGen above work for you?

[anton-k]

I'm sorry to say but I've tried it for an hour and have failed to create working snippet for WORKSPACE.
In your gazelle repo you list small snippets that have to be used but don't list a whole example of workspace.

I've tried those snippets and they produce various errors.
Also I've tried to use WORKSPACE form the example directory which seems to require nix and I can not use it.
This idea of the need for nix to use bazel seems odd. It's like you need to install OS in virtual machine instead of using it directly

So I can not report back on that workaround as I've failed to setup the things.
Prior to that I've used this repo to try to setup things: https://github.com/github/semantic

[aherrmann]

I'm sorry to say but I've tried it for an hour and have failed to create working snippet for WORKSPACE.
In your gazelle repo you list small snippets that have to be used but don't list a whole example of workspace.

I'm sorry to hear you're struggling with this. The Gazelle repo includes a full setup, the corresponding local snapshot is here, and the stack_snapshot invocation is here. The important part is the local_snapshot (you will have to replace ghc_version to fit your setup) and the setup_deps (you may need to adjust the entries to fit your dependencies, e.g. "regex-base": ["@stackage//:Cabal"],).

If that doesn't work, could you share your WORKSPACE, your snapshot.yaml, and the error you're encountering?

This idea of the need for nix to use bazel seems odd. It's like you need to install OS in virtual machine instead of using it directly

The use of Nix in rules_haskell is optional, if you don't want to use Nix, then you don't have to. You can take a look at this blog post or at this talk if you're interested in the motivation for Nix+Bazel.

[anton-k]

Thanks for thorough reply and guidance. I'll study it and will try again. I'll report on my progress. Thanks again for guidance and this project

[avdv]

Please note that a workaround was also added to rules_haskell during the upgrade to GHC 9.2.5 - see #1869

Also, GHC 9.6.1 is shipping with Cabal 3.10.1 which includes the fix for this bug.