Matching hie GHC version to the project GHC version

[alanz]

Come up with a process to launch the right hie, to match the compiler. And this has to work for stack and cabal, so stack install is not an option, necessarily.

I think there are two alternative approaches

1. Make a concierge process that does the initial handshake until the initialize message with the project root is given, then detect the GHC version and spawn the appropriate hie version. The trick will be to replace the one process with the other, or to delegate stdio to the spawned hie. With the current state of initialization.

2. Expose a helper that the client can invoke when determining the project root that also returns the hie instance to use.

The second option may be simpler, and can fall back to just using a setting in the client. These things tend to be pretty stable.

[alanz]

Also, report an error if we discover that a project is using a mismatched GHC, via an LSP error message.

[Tehnix]

As a temp fix, currently I'm using a wrapper script around HIE to make it start the right hie version,

#!/usr/bin/env bash
DEBUG=1
indent=""
function debug {
  if [[ $DEBUG == 1 ]]; then
    echo "$indent$@" >> /tmp/hie-wrapper.log
  fi
}

curDir=`pwd`
debug "Launching HIE for project located at $curDir"
indent="  "

GHCBIN='ghc'
# If a .stack-work exists, assume we are using stack.
if [ -d ".stack-work" ]; then
  debug "Using stack GHC version"
  GHCBIN='stack ghc --'
else
  debug "Using plain GHC version"
fi
versionNumber=`$GHCBIN --version`
debug $versionNumber

HIEBIN='hie'
BACKUP_HIEBIN='hie'
# Match the version number with a HIE version, and provide a fallback without
# the patch number.
if [[ $versionNumber = *"8.0.1"* ]]; then
  debug "Project is using GHC 8.0.1"
  HIEBIN='hie-8.0.1'
  BACKUP_HIEBIN='hie-8.0'
elif [[ $versionNumber = *"8.0.2"* ]]; then
  debug "Project is using GHC 8.0.2"
  HIEBIN='hie-8.0.2'
  BACKUP_HIEBIN='hie-8.0'
elif [[ $versionNumber = *"8.0"* ]]; then
  debug "Project is using GHC 8.0.*"
  HIEBIN='hie-8.0'
elif [[ $versionNumber = *"8.2.1"* ]]; then
  debug "Project is using GHC 8.2.1"
  HIEBIN='hie-8.2.1'
  BACKUP_HIEBIN='hie-8.2'
elif [[ $versionNumber = *"8.2.2"* ]]; then
  debug "Project is using GHC 8.2.2"
  HIEBIN='hie-8.2.2'
  BACKUP_HIEBIN='hie-8.2'
elif [[ $versionNumber = *"8.2"* ]]; then
  debug "Project is using GHC 8.2.*"
  HIEBIN='hie-8.2'
else
  debug "WARNING: GHC version does not match any of the checked ones."
fi

if [ -x "$(command -v $HIEBIN)" ]; then
  debug "$HIEBIN was found on path"
elif [ -x "$(command -v $BACKUP_HIEBIN)" ]; then
  debug "Backup $BACKUP_HIEBIN was found on path"
  HIEBIN=$BACKUP_HIEBIN
else
  debug "Falling back to plain hie"
  HIEBIN='hie'
fi

$HIEBIN $@

And to built the different binaries from source, I use (with some redundancies),

stack --stack-yaml=stack-8.0.2.yaml install \
  && cp ~/.local/bin/hie ~/.local/bin/hie-8.0.2 \
  && cp ~/.local/bin/hie ~/.local/bin/hie-8.0 \
  && stack --stack-yaml=stack-8.2.1.yaml install \
  && cp ~/.local/bin/hie ~/.local/bin/hie-8.2.1 \
  && cp ~/.local/bin/hie-8.2.1 ~/.local/bin/hie-8.2 \
  && stack --stack-yaml=stack.yaml install \
  && cp ~/.local/bin/hie ~/.local/bin/hie-8.2.2 \
  && cp ~/.local/bin/hie-8.2.2 ~/.local/bin/hie-8.2

I don't know if this could be useful for others? I currently have just put it on my path, and then altered the VSCode plugin to call hie-wrapper instead of plain hie.

^ the temporary VSCode edits specifically are, in ~/.vscode/extensions/alanz.vscode-hie-server-0.0.7/hie-vscode.sh (hie => hie-wrapper),

export HIE_SERVER_PATH=`which hie-wrapper`

...

# Run directly
hie-wrapper --lsp $@
...

Finally, one can see what's going on with tail -f /tmp/hie-wrapper.log, or change DEBUG to 0, if they don't want these messages.

[Tehnix]

While this would preferably be in Haskell, I think this provides a fine transition until we get that part integrated fully. Furthermore, if we get any form of binaries built for HIE, we can easily extend the script to also download these binaries, if they are not found for the specific GHC version. I'd be more than happy to do that part (if it's something we want to continue with) :)

[alanz]

I think this is a great step, and basically what I had in mind for the initial approach anyway.

And the only future change would be to rewrite the wrapper in haskell, which should help with it being more cross-platform friendly.

And possibly extending cabal-helper to spit out the GHC version for us.

[Tehnix]

I'm a little unsure on the next step. It can easily be added to the VSCode hie-vscode.sh and I can change the Atom integration to launch through a script instead of HIE directly, but stuff like Neovim would be left for manual setup of the script.

Should I just go ahead with the two first, and then perhaps make a README entry under Neovim on how to add the wrapper script? It would mean keeping a minimum of two places in sync (Atom, VSCode), but I guess we can live with this for now.

[alanz]

I think we should add the wrapper to the vscode repo, and the build script to hie (perhaps as a Makefile?), but make the use of the wrapper in vscode subject to a config setting, which does not use it by default. We can flip that default later.

…

On 24 January 2018 at 11:50, Christian Kjær ***@***.***> wrote: I'm a little unsure on the next step. It can easily be added to the VSCode hie-vscode.sh and I can change the Atom integration to launch through a script instead of HIE directly, but stuff like Neovim would be left for manual setup of the script. Should I just go ahead with the two first, and then perhaps make a README entry under Neovim on how to add the wrapper script? It would mean keeping a minimum of two places in sync (Atom, VSCode), but I guess we can live with this for now. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#439 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAZAB34MJNP0tEBxNZ2GRBr6mbVGXyBpks5tNvzdgaJpZM4RaZO_> .

[Tehnix]

I'll start working on it 👍

[Tehnix]

Should all be done, I'll make the README update after the remaining PRs are merged.

[alanz]

This is now supported (configuration-wise) in emacs, via emacs-lsp/lsp-haskell#9

[alanz]

The best way forward may be some kind of concierge process that receives the LSP initialize message from the client, determines the project GHC version, and then calls something like exec to replace itself with the right one.

See http://hackage.haskell.org/package/unix-2.7.2.2/docs/System-Posix-Process.html#v:executeFile and
https://stackoverflow.com/questions/4204915/please-explain-the-exec-function-and-its-family