cabal wrapper uses always global ghc in PATH #194

jneira · 2020-06-10T12:25:19Z

detected when testing ghcide in itself (see https://github.com/digital-asset/ghcide/issues/610)
although you set the field with-compiler: ghc-8.6.5 in the cabal.project hie-bios was using my default ghc in path (ghc-8.8.3)

PS D:\dev\ws\haskell\ghcide> ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.8.3
PS D:\dev\ws\haskell\ghcide> ghcide --version
ghcide version: 0.2.0 (GHC: 8.6.5) (PATH: D:\bin\ghcide.exe)
PS D:\dev\ws\haskell\ghcide> cat .\cabal.project
packages: .

with-compiler: ghc-8.6.5
PS D:\dev\ws\haskell\ghcide> cabal clean
PS D:\dev\ws\haskell\ghcide> ghcide
ghcide version: 0.2.0 (GHC: 8.6.5) (PATH: D:\bin\ghcide.exe)
Ghcide setup tester in D:\dev\ws\haskell\ghcide.
Report bugs at https://github.com/digital-asset/ghcide/issues

Step 1/4: Finding files to test in D:\dev\ws\haskell\ghcide
Found 63 files

Step 2/4: Looking for hie.yaml files that control setup
Found 3 cradles

Step 3/4: Initializing the IDE

Step 4/4: Type checking the files
[INFO] Consulting the cradle for "D:\\dev\\ws\\haskell\\ghcide\\src\\Development\\IDE\\GHC\\WithDynFlags.hs"
> Resolving dependencies...
> Build profile: -w ghc-8.8.3 -O1
> In order, the following will be built (use -v for more details):
>  - ghcide-0.2.0 (lib) (first run)
> Configuring library for ghcide-0.2.0..
> Preprocessing library for ghcide-0.2.0..
File:     D:\dev\ws\haskell\ghcide\src\Development\IDE\GHC\WithDynFlags.hs
Hidden:   no
Range:    1:0-100001:0
Source:   compiler
Severity: DsError
Message:
  <command line>: cannot satisfy -package-id aeson-1.5.1.0-1e42a0cdbd4b065e4d6f1c804d63f35706230918:
  aeson-1.5.1.0-1e42a0cdbd4b065e4d6f1c804d63f35706230918 is unusable due to missing dependencies:
  attoparsec-0.13.2.4-04e8dfec95c5fe0d96babd7d76d0463f6955b1db base-4.13.0.0
  base-compat-b_-0.11.1-1ae618f5c56712e963c7c424698817f24ad5c97a bytestring-0.10.10.0

hypothesis:
- the wrapper is calling "ghc" with no args for all invocations with no --interactive
  https://github.com/mpickering/hie-bios/blob/293baaf793f82f639affe734ebe785ccdcafd40b/wrappers/cabal.hs#L19
- cabal calls ghc --numeric-version, being "ghc" the programs passed in -w as first option, to know the actual ghc version in use

PS D:\dev\ws\haskell\ghcide> ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.8.3
PS D:\dev\ws\haskell\ghcide> cat .\cabal.project
packages: .

with-compiler: ghc-8.6.5
PS D:\dev\ws\haskell\ghcide> cabal exec ghc -- --version
Resolving dependencies...
The Glorious Glasgow Haskell Compilation System, version 8.6.5
PS D:\dev\ws\haskell\ghcide> cabal exec ghc --with-compiler=ghc-8.8.3 -- --version
Resolving dependencies...
The Glorious Glasgow Haskell Compilation System, version 8.8.3
PS D:\dev\ws\haskell\ghcide>

so it is ignoring the original ghc used in by hie-bios (ghcPath here )

Possible solutions:

Use an intermmediate env var (HIE_BIOS_WRAPPER_GHC?) to inform the wrapper about the real ghc
Pass a new argument to the wrapper --hie-bios-ghc and use it, removing it before calling the real ghc

The text was updated successfully, but these errors were encountered:

jneira · 2020-06-10T21:32:55Z

Another test, using directly the wrapper:

PS D:\dev\ws\haskell\ghcide> cat .\cabal.project
packages: .
with-compiler: ghc-8.6.5
PS D:\dev\ws\haskell\ghcide> cabal exec ghc -- --version
Resolving dependencies...
The Glorious Glasgow Haskell Compilation System, version 8.6.5
PS D:\dev\ws\haskell\ghcide> cabal --with-compiler=C:\Users\atrey\AppData\Local\hie-bios\wrapper-3496bab802428a4b095415cdb49e49be.exe exec ghc -- --version
Resolving dependencies...
The Glorious Glasgow Haskell Compilation System, version 8.8.3

fendor · 2020-06-11T08:04:20Z

I can confirm the behaviour on linux, too.
The hypothesis seems to be correct!

Possible fixes:

Find the appropriate GHC version in Cradle.hs (via cabal-install-parsers?) and pass it via an environment variable to the wrapper.
Wait for cabal show-build-info to land (show-build-info (exe:cabal part plus tests) cabal#6241) since it will fix all our problems.
- Document why it doesn't work and how to work around it.

Unless a lot of users complain about this issue, I am in favour of the latter, as it will be just a few months and solve the issue for good.
Any work-around will be code cruft very soon.

jneira · 2020-06-11T09:06:19Z

Fair enough, moreover, cabal action uses global ghc in two points:

the wrapper
when compiling the wrapper itself, it usually does not throw any error cause the wrapper is dead simple code but it would throw it if you are using cabal but you dont have ghc in global path (nix?)

fendor · 2020-06-12T20:17:07Z

I think this issue is related: #148

jneira · 2021-07-30T12:11:49Z

A nice workaround if you use ghcup was mentioned by @hasufell in irc: open a terminal in the project dir root and do PATH=$(ghcup whereis -d ghc <ghc-ver>):$PATH && code .

hasufell · 2021-07-30T14:16:47Z

Wait for cabal show-build-info to land (show-build-info (exe:cabal part plus tests) haskell/cabal#6241) since it will fix all our problems.

That was one year ago...

fendor · 2021-07-30T14:24:26Z

Back then it seemed like a reasonable expectation that it was going to be merged soon

hasufell · 2021-07-30T14:53:55Z

Back then it seemed like a reasonable expectation that it was going to be merged soon

The dream

jneira · 2021-07-30T15:06:17Z

A nice workaround if you use ghcup was mentioned by @hasufell in irc: open a terminal in the project dir root and do PATH=$(ghcup whereis -d ghc <ghc-ver>):$PATH && code .

if you don't have ghcup you can do simply PATH=$(cabal exec which -- ghc):$PATH && code .

jneira · 2021-07-30T15:08:06Z

Back then it seemed like a reasonable expectation that it was going to be merged soon

The dream

third time is the right time

hasufell · 2021-07-30T15:25:16Z

A nice workaround if you use ghcup was mentioned by @hasufell in irc: open a terminal in the project dir root and do PATH=$(ghcup whereis -d ghc ):$PATH && code .

Here's a bash function for your .bashrc:

with_ghc() {
  local np=$(ghcup --offline whereis -d ghc $1 || { ghcup --cache install ghc $1 && ghcup whereis -d ghc $1 ;})
  if [ -e "${np}" ] ; then
    shift
    PATH="$np:$PATH" "$@"
  else
    >&2 echo "Cannot find or install GHC version $1"
    return 1
  fi
}

And for your fish config:

function with_ghc
  set --local np (ghcup --offline whereis -d ghc $argv[1] ; or begin ghcup --cache install ghc $argv[1] ; and ghcup whereis -d ghc $argv[1] ; end)
  if test -e "$np"
    PATH="$np:$PATH" $argv[2..-1]
  else
    echo "Cannot find or install GHC version $argv[1]" 1>&2
    return 1
  end
end

use:

with_ghc 8.10.5 sh -c 'echo $PATH'
with_ghc 8.10.5 cabal build
with_ghc 8.10.5 code .

Edit: I feel I just reimplemented stack.

hasufell · 2021-09-09T09:39:29Z

Since the cabal patch is merged, I guess this can move forward

fendor · 2021-09-09T11:17:03Z

Yep, but not quite ideal yet, as we still have no quick way of querying for the project ghc. Currently, it requires to build at least one cabal component.

hasufell · 2021-09-09T11:19:02Z

Currently, it requires to build at least one cabal component.

Well, that means if I run cabal build before starting the language server, it should work?

fendor · 2021-09-09T11:22:01Z

if you launch the correct language server (e.g. 8.6.5 for projects that use 8.6.5) then it will work (assuming MR #301) even without running cabal build beforehand. But hls-wrapper will still pick up the wrong ghc version and launch the wrong language server.

fendor · 2021-09-09T11:30:58Z

BTW, MR #301 is not correct currently, as it does not use the latest json lib decoder/encoder for build-info.

jneira · 2021-11-09T13:35:06Z

The last promising hack to get the path to ghc could be:

cabal exec ghc -- -package-env=- -e 'System.Environment.getExecutablePath'

ugly but seems to work for now.

-package-env=- is needed to bypass the GHC_ENVIRONMENT value set by cabal to pass the packagedb stack to ghc as it makes the one liner fail withou a full build, which creates effectively that packagedb stack

The error without that option and without the costly full build is:

ghc: can't find a package database at /home/hugin/Documents/haskell/hie-bios/dist-newstyle/packagedb/ghc-8.10.4

Talking with @fendor it seems i can be used in a more direct way than #282 so maybe it could be used in another smaller pr if i understood it correctly

jneira changed the title ~~windows cabal wrapper uses global ghc in PATH~~ cabal wrapper uses always global ghc in PATH Jun 10, 2020

jneira mentioned this issue Aug 25, 2020

ghc version mismatch with cabal cradle and alternative ghc in cabal.project haskell/haskell-language-server#351

Closed

fendor mentioned this issue Feb 1, 2021

Use the proper GHC version given by cabal #282

Merged

jneira mentioned this issue Jul 30, 2021

Allow specifying the GHC to be used for the cabal cradle #148

Closed

jneira linked a pull request Jul 30, 2021 that will close this issue

Use the proper GHC version given by cabal #282

Merged

jneira added can-workaround type: bug Something isn't working labels Jul 30, 2021

fendor closed this as completed in #282 Feb 22, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cabal wrapper uses always global ghc in PATH #194

cabal wrapper uses always global ghc in PATH #194

jneira commented Jun 10, 2020

jneira commented Jun 10, 2020

fendor commented Jun 11, 2020 •

edited

Loading

jneira commented Jun 11, 2020

fendor commented Jun 12, 2020

jneira commented Jul 30, 2021

hasufell commented Jul 30, 2021

fendor commented Jul 30, 2021

hasufell commented Jul 30, 2021

jneira commented Jul 30, 2021

jneira commented Jul 30, 2021

hasufell commented Jul 30, 2021 •

edited

Loading

hasufell commented Sep 9, 2021

fendor commented Sep 9, 2021

hasufell commented Sep 9, 2021

fendor commented Sep 9, 2021 •

edited

Loading

fendor commented Sep 9, 2021

jneira commented Nov 9, 2021 •

edited

Loading

cabal wrapper uses always global ghc in PATH #194

cabal wrapper uses always global ghc in PATH #194

Comments

jneira commented Jun 10, 2020

jneira commented Jun 10, 2020

fendor commented Jun 11, 2020 • edited Loading

jneira commented Jun 11, 2020

fendor commented Jun 12, 2020

jneira commented Jul 30, 2021

hasufell commented Jul 30, 2021

fendor commented Jul 30, 2021

hasufell commented Jul 30, 2021

jneira commented Jul 30, 2021

jneira commented Jul 30, 2021

hasufell commented Jul 30, 2021 • edited Loading

hasufell commented Sep 9, 2021

fendor commented Sep 9, 2021

hasufell commented Sep 9, 2021

fendor commented Sep 9, 2021 • edited Loading

fendor commented Sep 9, 2021

jneira commented Nov 9, 2021 • edited Loading

fendor commented Jun 11, 2020 •

edited

Loading

hasufell commented Jul 30, 2021 •

edited

Loading

fendor commented Sep 9, 2021 •

edited

Loading

jneira commented Nov 9, 2021 •

edited

Loading