Using `ghc-paths` makes downstream executables non portable

[jneira]

• We have detected in haskell-language-server executable that libraries using this package might fail due to /opt/ghc/8.8.4/lib/ghc-8.8.4/settings: openFile: does not exist (No such file or directory)
  • brittany: https://github.com/haskell/haskell-language-server/issues/412 and https://github.com/lspitzner/brittany/issues/315
  • apply-refact: https://github.com/haskell/haskell-language-server/issues/591
• The suspicious dependency is ghc-path, as it stores the ghc libdir at compile time

https://github.com/alanz/ghc-exactprint/blob/81c2ef9cdcf284724df0d66ef1fe5616fdc8ae6c/src/Language/Haskell/GHC/ExactPrint/Parsers.hs#L289

• The solution could be try to get the libdir at runtime and only use ghc-paths as last resort, like it is done in hie-bios:

https://github.com/mpickering/hie-bios/blob/5eede133dbe82d158591a2c8d0361b3d188192ed/src/HIE/Bios/Environment.hs#L66-L81

But is supposes a runtime call to ghc, that in turn could need be called through stack or cabal, maybe too much.

Or take the way of let downstream packages inform the libdir location, or the ghcWrapperas a callback... :thinking:

[jneira]

As the package is using the libdir only in the public function withDynFlags, remove its use downstream should fix the issue

https://github.com/alanz/ghc-exactprint/blob/81c2ef9cdcf284724df0d66ef1fe5616fdc8ae6c/src/Language/Haskell/GHC/ExactPrint/Parsers.hs#L155-L159

[zliu41]

Besides withDynFlags, ghcWrapper is also used in some parse functions like parseModuleApiAnnsWithCpp.

If such functions take an additional libdir parameter, does that solve your problem?

ghc-exactprint doesn't know the path to the ghc executable, so I'm not sure how "a runtime call to ghc" would work.

[jneira]

ghc-exactprint doesn't know the path to the ghc executable, so I'm not sure how "a runtime call to ghc" would work.

the direct solution i can think off is pushing the ghc wrapper (better then the libdir location imo) or the data that is extracted using it (dynflags and...) downstream and require client code to provide it, in a new function (or several), falling back to the actual one

EDIT: whoops you were suggesting just that :smile:

[jneira]

Tbh i think #98 only can be a temporary workaround, as the code using env it is not thread safe anymore (among other considerations). Not sure if it worths start to work in a better solution for the lib, given it will be included in ghc sooner or later. @alanz iirc you put a link in irc with a new solution for the ghc wrapper but i cant find it out right now, sorry, maybe we could port that one.