Haskell-ide-engine: Perhaps update documentation to include '--copy-compiler-tool' option instead of using 'stack install'

[EdmundsEcho]

I'm just getting started with what I know has been a lot of work in this project. Installing hie is indeed time consuming. Is there harm/risk in calling --copy-compiler-tool' option instead of using 'stack install? If not, is it advice that would be useful to include in the readme? - E

[samuelpilz]

What does --copy-compiler-tool to exactly? I could not find meaningful documentation of this flag.

[Anrock]

@power-fungus it copies a tool to a ghc-specific bin folder instead of global stack bin folder. So you can stack build --copy-compiler-tool --resolver=... to install tools on per-ghc basis instead of globally. I was using that with HIE some time ago and it was working just fine. And I think I raised a ticket about copy-compiler-tool vs hie-wrapper.

[samuelpilz]

This seems interesting. However, cabal does not have a feature like this. I would like to have only a single officially supported method of installation.

[EdmundsEcho]

I understand wanting to keep it as simple as possible. May I ask why stack is not going to be a supported way to install hie? It seems to me if you build for making it work with stack, you get the cabal capacity "for free". I say that of course because stack uses cabal "under the hood". Finally, my understanding is that maintaining the codebase on stack may/likely requires more work. However, that is because it notifies the maintainer of compatibility issues with the latest dependencies over time. It's kind of like why we like types so much... a pain the #!* but worth it :-)

[samuelpilz]

May I ask why stack is not going to be a supported way to install hie?

@EdmundsEcho There is more to installing hie than simply stack install. I described this in this document, which is the most-correct approximation of the requirements I found so far. The build script does rely on stack install in the background.

It seems to me if you build for making it work with stack, you get the cabal capacity "for free".

Generally, this is not the case - in neither direction. However, hie does work with both build systems.

I'm afraid, I still dont understand what you are proposing.

[EdmundsEcho]

Thank you for clarifying. The only question is whether there is any benefit or ability to "install locally" but in actuality, hie links to a global version of the tool. This is accomplished using copy-compiler-tool. If this suggestion were made somewhere in the documentation it might help reduce the "weight" of installing and maintaining the tool. Thank you again for this much needed Haskell dev tool. - E

[samuelpilz]

Currently, we use stack install and manage multiple installations ourselves by correctly renaming the binary to hie-x.y.z.

The only question is whether there is any benefit or ability to "install locally" but in actuality, hie links to a global version of the tool.

I don't understand the words you are using. What do you exactly mean by "install locally", what is the "tool" you are referring to?

Could you give a example-script how hie would use the copy-compiler-tool option?

[EdmundsEcho]

"install locally" -> local to the project (not globally on the user's computer)

Recommendation:
install hie -> install hie --copy-compiler-tool

The renaming management that hie does would happen in the global space. The recommended command would use the specific instance/version in the global space to service the project. In the event the global space does not have the version required by the project, stack will download and install the needed version, install it in the global space, and make it available to the project from where the command was made.

[samuelpilz]

I looked into this a bit. The hie executable is installed into $STACK_ROOT/compiler-tools/.../ghc-8.6.5/bin, which is not in the global $PATH. Now, hie has to be started with stack exec hie. This can be regarded as an improvement, however, the hie-wrapper would have to change to be aware of this installation method.

[Anrock]

the hie-wrapper would have to change to be aware of this installation method.

Hm, if all HIEs are installed with --copy-compiler-tool you don't need hie-wrapper at all. Stack will handle selecting proper hie via its per-ghc sandboxes. You only need to change invocation of hie in lsp config from hie-wrapper to stack exec hie.

[samuelpilz]

This is what I meant. However, some people dislike stack and this approach has nothing equivalent in cabal. Is this an issue?

[Anrock]

I dunno, but imo it isn't an issue for cabal users if some stack-specific thing is documented. However another way of installing/running hie would make debugging/maintaining/troubleshooting harder.

[fendor]

I agree with @Anrock, it would make maintenance harder with no real benefit (at least, to me).

[samuelpilz]

Documenting something that works simple. However, the proposed change does not "simply work" and supporting other ways to install hie is a lot of work.