Proposal: remove install.hs script

[jneira]

• The install script was long time ago almost the unique way to install haskell-ide-engine and hls in its origins
• It is mentioned in documentation as the main way to build hls from source: https://haskell-language-server.readthedocs.io/en/latest/installation.html#building
• It mainly uses cabal install/stack install to install hls and hls-wrapper and then make a copy as hls-${ghc-version}. It only hides the hls-wrapper looking for hls-${ghcVersion} machinery
• However
  • now you can install hls from source with ghcup without even having to do the checkout
  • there are lot of ways to get prebuilt binaries so regular users do not even know the install script
  • and power users can do the hls-${ghcVersion} thing with one command
  • the script needs one stack-${ghcVersion}.yaml for each supported ghc version to work so we cant consider changing stack.yaml's without taking in account the script

//cc @simonmichael @fendor as recently we discussed this in the irc channel

[simonmichael]

More context: I was trying to help clean up the stack yamls to reduce their maintenance cost and perceived drag on contributions. I think the stack yamls exist for these reasons:

1. to make building (and contributing) easy and reliable for stack users, no matter which version of ghc they have or must use on their platform
2. to document a known-good build plan for each major ghc version
3. to support the install script, which expects a number of stack-X.Y.yaml files.

I just learned about the install script, and had questions about it:

and the install script uses the stack yamls.. why ? because they are the most reliable ?

and who uses this install script.. a few folks, you reckon ? who don't want to use ghcup ?

the install script looks cool, but I wonder 1. who uses it 2. who knows about it 3. how you discover it 4. when it's the best solution 5. why it's needed ....

could it be retired, now that ghcup is popular ? I had never heard of hls-install

[jneira]

I think i somewhat responded to some questions in the issue description

and the install script uses the stack yamls.. why ? because they are the most reliable ?

not sure how could the install script build hls using stack underneath for a ghc version without a preexistent stack.yaml

and who uses this install script.. a few folks, you reckon ? who don't want to use ghcup ?

not sure, maybe some users who are used to it from the days it was the unique way to install hls
we can use this issue to let them know we are thinking in remove it and complain about 😄

[jneira]

Ok, if nobody disagree a plan could be:

• Announce the install script deprecation in the next release (1.6.0), pointing to this issue to allow users comment about
• Make a pr to update doc installation instructions adding new ones without using the script and noting it is deprecated, just before or after the release
• After 1.7.0 remove the install script and any mention in docs (but a small note noticing it is not available anymore)

[jhrcek]

I'm using ./install.hs script quite regularly to build latest hls from master branch.
I had no idea ghcup can install hls from source. Could you please point me for some documentation about this so I can try it?
If it works, I'd have no problem with removing the install script.

[fendor]

and the install script uses the stack yamls.. why ? because they are the most reliable ?

Stack used to be the only supported way to build HIE (three years ago?) reliably, since the install instructions used to be quite elaborate. I dont remember details (back then I probably didn't understand them properly anyway). After we started supporting cabal, we were in a weird limbo, where you could use cabal to install HIE using stack. Once we finally fixed this slight monstrosity, stack-*.yaml remained as the official documentation of which GHC versions HIE supported. E.g. adding even an empty stack-8.10.2.yaml allowed you to install HIE with cabal using GHC 8.10.2. Only the version number mattered, not the contents of the yaml file. I had the opinion, it would be easier to maintain if we didn't hardcode the supported GHC versions in the install script but derive it from the existing stack.yaml files. The script was copied over to HLS pretty much unchanged, thus this remnant of using stack.yamls to discover supported GHC versions remained.

and who uses this install script.. a few folks, you reckon

I occasionally use it, since it sets up the proper copied and symlinks. One-step solutions are nice.

could it be retired, now that ghcup is popular ?

While I like the one-line solution to install HLS and the wrapper, setting up all the correct paths (which makes it easier to override a specific HLS version and use it in your editor, afaict), I think we can retire it, assuming no one uses it anymore for anything mission critical.

[simonmichael]

@jhrcek what does the script give you ? (excuse my ignorance). I wonder what alternatives there may be.

Attempting to answer myself: the hls-install tool

• is under documented
• simplifies building hls binaries from source, for each ghc version, using stack or cabal
• is a mixed stack/cabal script; it tries to run reliably from either a stack or cabal one-line command
• is a shake script, offering various subcommands/targets and possibly using shake's dependency engine
• does some ghcup-like detection of installed ghc and hls versions
• runs either stack or cabal, with a bunch of code for handling each one
• to build.. the hls source in the parent directory ? for each ghc version detected in path (if using cabal) or with a stack-X.Y.yaml file in the parent directory (if using stack) ?
• tries to help text-icu build on mac by installing icu4c. This is fragile (won't work on arm macs where brew paths have changed)

[simonmichael]

PS my original interest in install/hls-install was that I proposed to rename stack-8.10.7.yaml to stack.yaml, instead of maintaining two stack yaml files that are (should be) identical (#2501). But this would cause problems for / require changes to install. If install is no longer needed, that extra stack yaml could be dropped. Beyond this I have not much opinion on install, except

• it looks like a nice framework for future more extensive scripting, if that is needed
• who needs it when, who uses it, how it can be discovered, the real value it provides, the cost of keeping it around, should be considered/quantified.

[jhrcek]

what does the script give you ?

Don't get me wrong, I'm not against removing the script.
Until now the install script was just a convenient way form me to install HLS from source with latest changes.
I could just do stack ./install.hs hls-8.10.7 or stack ./install.hs hls-8.8.4 without worrying about details.
If we remove the script I'd just like similarly convenient way to build from source for a particular version of GHC that my projects depend on.

[jneira]

I'm using ./install.hs script quite regularly to build latest hls from master branch. I had no idea ghcup can install hls from source. Could you please point me for some documentation about this so I can try it? If it works, I'd have no problem with removing the install script.

sure, there is a mention here: https://haskell-language-server.readthedocs.io/en/latest/installation.html#ghcup

examples taken from ghcup compile hls --help:

  # compile 1.4.0 for ghc 8.10.5 and 8.10.7
  ghcup compile hls -v 1.4.0 -j 12 --ghc 8.10.5 --ghc 8.10.7
  # compile from master for ghc 8.10.7, linking everything dynamically
  ghcup compile hls -g master -j 12 --ghc 8.10.7 -- --ghc-options='-dynamic'

[jneira]

is under documented

well it is documented in the official docs with detail as the main way to build hls from source: https://haskell-language-server.readthedocs.io/en/latest/installation.html#building

is used to build hls from source (unlike ghcup, which installs prebuilt binaries.. right ?)

ghcup can build hls from source too and some use cases or workarounds needs building from source

[simonmichael]

I knew there'd be more more docs somewhere. If the script remains, https://haskell-language-server.readthedocs.io/en/latest/installation.html#building could be made discoverable from install.hs and install/README.md.

[simonmichael]

I guess ghcup can't build an arbitrary version of hls, eg an experimental branch ?

[jneira]

I guess ghcup can't build an arbitrary version of hls, eg an experimental branch ?

ghcup can build any arbitrary hls version from any repo + commit: see ghcup compile hls --help for more details

@jhrcek have you got the chance to try ghcup to see if it can be used for your workflow?

[jhrcek]

Yes, feel free to get rid of the install script.
I now know how to install hls using both ghcup as well as using plain cabal install.
Thanks for taking my use case into consideration!

[michaelpj]

It got removed.