search

haskell / haskell-ide-engine

The engine for haskell ide-integration. Not an IDE
BSD 3-Clause "New" or "Revised" License
2.38k stars 213 forks source link

Package `hie` binaries #1068

Open samuelpilz opened 5 years ago

samuelpilz commented 5 years ago

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:

mpickering commented 5 years ago

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 commented 5 years ago

For arch linux users: You can now download binary version from archlinuxcn repo: https://github.com/archlinuxcn/repo/issues/1044

samuelpilz commented 5 years ago

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:

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 commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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

alanz commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

poscat0x04 commented 4 years ago

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

andys8 commented 4 years ago

@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/