package uses hardcoded at compile time path to ghc libdir - Githubissues

lspitzner / brittany

haskell source code formatter

GNU Affero General Public License v3.0

690 stars 72 forks source link

package uses hardcoded at compile time path to ghc libdir #315

Closed jneira closed 2 years ago

jneira commented 4 years ago

The problem arise in hls when trying to use the brittany formatter plugin, using the precompiled binaries in the ci environment: see https://github.com/haskell/haskell-language-server/issues/412

Users got errors like:

/Users/runner/.ghcup/ghc/8.8.4/lib/ghc-8.8.4/settings: openFile: does not exist (No such file or directory)

The concrete path varies per os.

Ideally it should use the libdir at runtime, falling back to the compile time one

jneira commented 4 years ago

Afaics the package does not use ghc-paths directly, you can remove it from build-depends and it still compiles (so it is needed to ensure some version bounds??). I guess it could be used via ghc-exactprint: https://github.com/alanz/ghc-exactprint/blob/81c2ef9cdcf284724df0d66ef1fe5616fdc8ae6c/src/Language/Haskell/GHC/ExactPrint/Parsers.hs#L289

jneira commented 3 years ago

Opened issue upstream: https://github.com/alanz/ghc-exactprint/issues/96

jneira commented 3 years ago

Afacs ghc-exactprint only uses CHC.Paths for the public funcion withDynFlags. I cant find any use of that function in the brittany code base so it is a misterious for me how the error is triggered within brittany , maybe another package upstream is using it? :thinking:

tfausak commented 3 years ago

I'm not entirely sure what to do here. Requiring ghc-paths is a consequence of using GHC for parsing. It would be nice if we could do something different, but I think it would require help from one of ghc-exactprint, ghc-paths, or GHC itself.

This issue seems related: https://gitlab.haskell.org/ghc/ghc/-/issues/10961

jneira commented 3 years ago

@tfausak thanks for care. It turns out that ghc-exactprint is using it in other points and yeah, it should be changed there (and hen maybe adapt downstream packages) The correlated issue in ghc-exactprint is the linked above: https://github.com/alanz/ghc-exactprint/issues/96

jneira commented 3 years ago

Hi, i've introduced a hackish workaround to provide the runtime ghc libdir to ghc-exactprint, using an evironment variable: https://github.com/alanz/ghc-exactprint/pull/98 and i've used it in hls with success However i would not use it in the library cause the code would not be thread safe, the original issue is still open: https://github.com/alanz/ghc-exactprint/issues/96

azimut commented 3 years ago

If there is a workaround on mainstream. This means that a new binary release needs to be uploaded, right?

jneira commented 3 years ago

@azimut oh, sure, i was focusing in the library component but the executable here could use the workaround

tfausak commented 2 years ago

This should no longer be the case as of version 0.14.0.0. Please re-open if that’s not true.