Package hie binaries

[samuelpilz]

I would like to package the hie binaries with some linux package managers (maybe starting with by distribution archlinux and put the package haskell-ide-engine-bin on the aur)

I am not quite sure what is needed for a correct build of hie. Could it be that it is necessary to:

• install hie-* to $PATH
• install hie-wrapper to $PATH
• install cabal-helper-wrapper to $PATH

[mpickering]

HIE is packed for nix already. It could be useful to look at that to see what wrappers are needed and so on - https://github.com/domenkozar/hie-nix

[LinArcX]

For arch linux users:
You can now download binary version from archlinuxcn repo:
archlinuxcn/repo#1044

[samuelpilz]

I have tried to analyze this situation. A standalone-binary distribution faces the issue that there are many runtime dependencies. Some of them cannot be easily provided by a binary-distribution. Having stack and the binary hie is not sufficient.

I have done:

1. build hie on the host machine
2. setup a fresh VM (archlinux), install stack and git and setup path for .local/bin
3. copy hie binary to guest VM
4. install atom and visual studio code (from archlinux repositories) and appropriate plugins
5. Nothing worked. Errors: hoogle db not found and cabal-install not installed,
6. I did stack build hoogle; stack exec hoogle generate
7. stack install cabal-install
8. Nothing worked. error: $HOME/.local/bin/data/hlint.yaml was not found
9. create empty file $HOME/.local/bin/data/hlint.yaml
10. Nothing worked. errors: cabal-helper-wrapper not found.
11. Copy cabal-helper-wrapper (found via stack exec which -- cabal-helper-wrapper) from host
12. Nothing worked. Error: file .../.stack/.../ghc-8.6.4/lib/ghc-8.6.4/settings missing (path is to ghc on host, which was used to compile ``)
13. building cabal-helper from within the guest was not successful (Could not resolve dependencies ...).
14. I gave up (for now)

Conclusion
I found runtime-dependencies:

• cabal-install
• hoogle database generated by stack exec hoogle generate
• $HOME/.local/bin/data/hlint.yaml needs to be there, for whatever reason
• cabal-helper-wrapper needs to be present in cabal_helper_libexecdir.
• some settings file needs to be present for cabal-helper-wrapper

I would be interested in what the nix package does to mitigate these problems but I have not the experience with nix so I cannot find out how they do it

[jneira]

I think it would be great (necessary?) to have windows precompiled binaries, too. AFAIK it is easier to maintain cause they usually work across different windows versions, without worry about dynamic linking.
The best approach could be use appveyor to generate them and upload to release assets auto (see how we did with dhall-haskell) f.e.
To avoid running out of space we could only generate artifacts for releases and maybe master branch, if possible.
The zip could contain all the runtime deps in relative paths, copying them from the appveyor host. We should use the appropiate config options to change default paths to relative ones, if possible.

[NickSeagull]

Is there a way that I can help with this? I'm on Windows so I can help with the Windows and the Linux version (I use WSL also)

[lorenzo]

@NickSeagull trying to package your local install and use in another machine, then document what or why it does not work would be of great help

[jneira]

It seems there is another runtime dependency involving brittany, is worth create a new issue @fendor?

[alanz]

@jneira I spoke with @lspitzner on IRC last night, and I think he is planning on exposing an API where we pass the parsed AST from hie-plugin-api, thus avoiding the run-time problem.

[jneira]

I think include binaries in releases still worth, although we are starting to move to haskell-language-server. @alanz Is there some update about the brittany change? can i help in some way?

[fendor]

@jneira I attempted to use pPrintModule for the formatting, but had a bunch of of problems that I could not easily solve (mainly understanding the API, etc...)

[alanz]

I don't know the current state of brittany, but I am pretty sure @lspitzner exposed the required API shortly after we discussed it. Then all we have to do is pass in the already-loaded typechecked (or parsed) module and we are good to go. We can ignore all the stuff about context, libdirs, etc

[poscat0x04]

We (archlinuxcn) are providing prebuilt binaries for Arch Linux.
We maintain an automated build bot that recompiles HIE whenever the upstream AUR repo updates.
The usage of our repo is described in the README file.
If you are using other distros you can unzip the package and move the binaries to wherever you want.
A build status page is also available.

[jneira]

@poscat0x04 wow that are great news, could we add that way to get binaries in the docs?

[poscat0x04]

Sure. I forgot to mention that packages are placed under https://repo.archlinuxcn.org/x86_64/ .

[andys8]

@poscat0x04 Are the binaries expected to work other OS like debian/ubuntu? (Update: Nope)
Having the binaries would be great :)

#!/bin/sh
VERSION="1.1-4"
cd /tmp
wget https://repo.archlinuxcn.org/x86_64/haskell-ide-engine-$VERSION-x86_64.pkg.tar.zst
tar -I zstd -xvf haskell-ide-engine-$VERSION-x86_64.pkg.tar.zst
cp usr/bin/* ~/bin/