ghc-mod should be told which version of cabal to use

[TomMD]

The below was found when using HIE on a cabal v2 project in which the top level directory had a cabal.project with packages in subdirectories containing the .cabal files. I would invoke neovim/hie from the project directory and open a file for editing such as $TOP/$package/src/file.hs.

ghc-mod uses cabal configure or new-configure conditionally based on a heuristic of checking for dist-newstyle in a working directory (see core/GhcMod/CabalHelper.hs for the config vs new-config and core/GhcMod/Cradle for the directory heuristic). If no newstyle directory is found it assumes v1.

1. I will ask ghc-mod to default assume v2 instead of v1.
2. ghc-mod uses the current working directory (due to withGhcModEnv or findCradle depending on code path). We need to be able to tell ghc-mod the directory. This will requires a ghc-mod patch which is then leveraged by hie. Does that sound good?

A quicker fix for HIE might be to not change the working directory to begin with... not sure where that is done honestly. I start neovim/hie-wrapper in the top level directory (project) but clearly ghc-mod is seeing the subdirectory (package).

[pigmej]

Actually the args that are passed to cabal-helper-wrapper are (besides many others) v1-style and explicit path to expected (and non existing for v2 projects) dist directory.

It will basically happen starting from cabal 3.0.0.0 while it's still rather fine on 2.4.1.0, because 3 switched to new style by default afaiu.

So the actual solution is probably to support v2 properly in HIE.

[TomMD]

Great. Cabal-install 3 is out so would PRs of this nature be welcome?

[fendor]

Do you mean do add PRs to ghc-mod to support cabal v2?
While they are welcome, there is an ongoing effort to support v2-commands, so, you should definitely communicate with the maintainers before submitting PRs.

[masaeedu]

@TomMD I'm very fuzzy on the details here, but shouldn't the decision be based on the version of cabal that's actually installed (i.e. on the PATH) instead of choosing some default?

[masaeedu]

@pigmej Do you know where that v1-style argument is coming from? I tried searching through this repo but couldn't find any mention of that.

[TomMD]

@masaeedu No, that seems the wrong decision. It is unlikely anyone is running a version of cabal that only supports v1 style. All recent cabals support v1 and v2.

My specific issue, which I'm guessing is or will be common, is that cabal v2 projects contain many cabal packages. If you use some ugly heuristic, such as looking for *.cabal files in the directory structure, then the tool will stop at the sub-project level and none of the dependencies (parallel packages) will be captures.

You see this issue doesn't lend itself to a heuristic based on files in the local directory nor does it lend itself to a guess based on the version of cabal. Personally I always start my editor from the project directory so there shouldn't be any need to guess but, as mentioned, the current working directory is being changed and tools including cabal wrapper and ghc-mod are quite confused even when I change the hie-passed argument to v2-style.

[TomMD]

@masaeedu "v1-style" is being passed by a submodule in submodules/cabal-helper/lib/Distribution/Helper.hs

[masaeedu]

@TomMD I'm using cabal 3, and I just want to use "v3-style" (which is what you get by default by using the cabal run, cabal build etc. commands). Maybe I'm misunderstanding what these vN-style arguments actually do. Could you enlighten me?

[TomMD]

No, there is no such thing as v3-style. Cabal up till about 2.2 used what is now called v1 style commands that installed packages globally (for some sense of global, it might be user based but not project based). Recently, most especially in 2.4 and 3.0, cabal and cabal-install have included a better set of operations which have been dubbed v2. This version has nothing to do with the cabal version - v2-install is the newest.

You can read the docs for what these operations do - they are off topic for this issue.

[masaeedu]

Thanks. I'm aware of the distinction between v1-style and v2-style, but I wasn't aware the now non-namespaced set of commands in cabal 3.0 (e.g. cabal run) is exactly identical to the v2 prefixed set of commands that was available in cabal 2.4. So I was assuming we'd need another check to dispatch to the non-namespaced commands if cabal 3.0 is installed.

[masaeedu]

Btw, do you have a branch or PR somewhere with your changes to get hie to invoke cabal-helper-wrapper with v2-style? I can't for the life of me figure out where that change needs to be made, even with your pointer to that file.

In my case I don't have any subprojects, so I'm hoping simply passing v2 instead of v1 will make things work.

[TomMD]

You need to git submodule update --init first - or just look at the cabal-helper repo which is where the code is (https://github.com/alanz/cabal-helper.git).

Just changing the v1-style string to v2-style does not suffice. You must also make it pass the correct directories for project and dist (well, dist-newstyle from the project directory instead of any sort of dist from the package directory under the project). I am not clear on where to make that change.

[masaeedu]

Thanks. I was looking for that in DanielG's repo instead of the fork, that's why I wasn't seeing it (git submodule update --init --recursive is broken on master because of the HaRE submodule pointing to a missing commit).

Would taking the approach of making v2 the default without regard to existence of dist/dist-newstyle in cabalCradle at least solve the half of the problem corresponding to getting ghc-mod to pass cabal-helper-wrapper the correct vN-style argument?

Specifically, in this check:

    isDistNewstyle <- liftIO $ doesDirectoryExist $ cabalDir </> "dist-newstyle"
    -- TODO: consider a flag to choose new-build if neither "dist" nor "dist-newstyle" exist
    --       Or default to is for cabal >= 2.0 ?, unless flag saying old style

If we instead do something like:

    isDistNewstyle <- liftIO $ cabalIsNewEnough

Then it will choose dist-newstyle anyway in the decisions that follow (the mkQuery bit right after).

That doesn't solve the issue with subpackages that you're mentioning, but it should fix single-cabal file projects, no?