Expose location of the ghc libdir in cradle.

[fendor]

Based on https://github.com/digital-asset/ghcide/issues/387#issuecomment-581151178, think about an API to obtain the libdir for a given Cradle.
First idea: Extend the cradle definition to query for the libdir, e.g:

data CradleAction a = CradleAction {
                      actionName :: ActionName a
                      , runCradle :: LoggingFunction -> FilePath -> IO (CradleLoadResult ComponentOptions)
                      , getLibdir :: IO FilePath
                      }

(location of the function getLibdir, as well as name, is subject to bikeshedding)
Currently, the default implementation for most cradles, except stack, would just call ghc --print-libdir while stack could call stack exec -- ghc --print-libdir. For cabal, we could do something similar.

A more generalized implementation could be to not expose a function to obtain the libdir but rather the path to the ghc version to use itself. Then other useful functions could be implemented with ease in application code, such as obtaining the ghc version to use in a cradle.

[fendor]

Exposing the path to the executable could be confusing though, when Cradle starts to abstract more compilers than just ghc, e.g. ghcjs.

[ndmitchell]

I'd rather hie-bios deals with it as things like Nix change the result based on environment variables, which I'm hoping you will get right!

[rsoeldner]

Any consense on how to solve this?

[pepeiborra]

This would be very useful indeed. My understanding is that libdir and path to binary are equivalent. You can find the libdir from the binary, and viceversa. So it doesn't really matter, and if the libdir is more general, that's probably the right choice

[lukel97]

I think we can use cabal exec which -- ghc and stack exec which -- ghc to get the GHC locations, and from there have a separate function in hie-bios which takes in a cradle and spits back the libdir, hijacked if needed with that NIX_GHC_LIBDIR thing.
If for some freak accident the path to the ghc no longer exists or fails to --print-libdir, then we can fall back to using ghc-path, which will still work if the user compiled from source

[fendor]

I think we can use cabal exec which -- ghc

Pretty sure this does not work unless the project has been already configured.

---

Would the proposed API make sense for you?

[lukel97]

I tested it on a clean project and it looks to be implicitly configuring the project beforehand, this is with cabal-install 3.2.0.0. The proposed API looks good though, makes much more sense than when where I put it (inside componentoptions). Something like

data CradleAction a = CradleAction {
                      actionName :: ActionName a
                      , runCradle :: LoggingFunction -> FilePath -> IO (CradleLoadResult ComponentOptions)
                      , getGhcPath :: IO (Maybe FilePath)
                      }

getGhcLibDir :: Cradle a -> IO FilePath

[lukel97]

Ugh just tested this on Linux, cabal-install 3.0.0 and got this strange bug

luke@debby:~/test-cabal-lib$ rm -r dist-newstyle/
luke@debby:~/test-cabal-lib$ cabal exec which -- ghc
Warning: The package list for 'hackage.haskell.org' is 140 days old.
Run 'cabal update' to get the latest list of available packages.
Resolving dependencies...
/home/luke/test-cabal-lib/dist-newstyle/tmp/environment.-24811: createDirectory: does not exist (No such file or directory)
luke@debby:~/test-cabal-lib$ ls dist-newstyle/
cache
luke@debby:~/test-cabal-lib$ mkdir dist-newstyle/tmp
luke@debby:~/test-cabal-lib$ cabal exec which -- ghc
/opt/ghc/bin/ghc

We can fix it by just creating a temporary directory though. Does this still happen on 3.2.0.0?

[lukel97]

Just tested, this is fixed on cabal-install 3.2.0.0. I don't think we should worry about this too much then

[hyperfekt]

If the libdir becomes first-class, it would be nice if its location could be customized.
Currently I have my cradle call Nix to return -no-global-package-db -package-db [libdir]/package.conf.d as extra arguments in order to change the set of dependencies without restarting the language server - but it would be cool if anyone could have that functionality without as much of a hassle.

[fendor]

I was wondering about ghcjs. Do we have to worry/think about it in the design of the API?

[lukel97]

@hyperfekt in #207, the location can be customised with the NIX_GHC_LIBDIR environment variable – would this work for your use case?

[hyperfekt]

@bubba Unfortunately not, because that environment variable cannot change after the language server is started. The entire idea is changing the libdir between restarts.

[fendor]

Implemented by #207

[lukel97]

@hyperfekt Does #215 semi-cover your use case? i.e. having the ability to call a separate bios program to return the libdir so it can be changed on the fly?

[hyperfekt]

@bubba Yeah, that would definitely do it!