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

New Issue

2020-09-25T07:34:10+02:00

jneira commented

2020-09-25 07:34:10 +02:00

(Migrated from github.com)

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

* 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

👍 7

jneira commented

2020-09-25 08:23:36 +02:00

(Migrated from github.com)

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: 81c2ef9cdc/src/Language/Haskell/GHC/ExactPrint/Parsers.hs (L289)

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

2020-11-12 11:10:57 +01:00

(Migrated from github.com)

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

jneira commented

2020-11-16 12:12:15 +01:00

(Migrated from github.com)

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? 🤔

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

2020-12-11 18:12:04 +01:00

(Migrated from github.com)

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

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

2020-12-11 19:18:14 +01:00

(Migrated from github.com)

@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

@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

2021-01-19 13:34:36 +01:00

(Migrated from github.com)

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

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

2021-02-19 22:44:10 +01:00

(Migrated from github.com)

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

jneira commented

2021-02-19 22:58:34 +01:00

(Migrated from github.com)

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

tfausak commented

2021-11-28 15:45:58 +01:00

(Migrated from github.com)

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

Sign in to join this conversation.

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: hexagoxel/brittany#315