Easy setup process

[NickSeagull]

In my opinion, the installation of HIE should be completely automatic for the user by default, unless someone is an advanced user that wants to tweak their install 🙂

This would avoid newbies shooting their foot when performing the install from scratch. If someone faces an issue like #1302 , by default they'll just uninstall HIE and switch to something else (or worse, to some other language 😬)

This issue would benefit a lot from #1068 , and if the user doesn't want to use binaries, they can always perform the manual install themselves.

The perfect setup ™

In my opinion, the initial setup should go something like this:

• Install an editor extension (for example for VSCode)
• The extension detects that HIE is not installed
• The extension prompts the user that if they want to install HIE
• The extension downloads and calls a script that performs all the necessary steps to install HIE:
  • Download all the tool binaries (hlint, hindent, etc...)
  • Download HIE binaries
  • Generate the hoogle DB
  • Install Stack or Cabal if the user doesnt care
  • ...

An example of this is IntelliJ IDEA, they even provide their own JDK so the user doesn't have to worry about that themselves.

Issues that must be solved before this

• Package hie binaries #1068
• stack install.hs build-all installs cabal in $HOME/.local/bin #1327
• HIE should generate local Hoogle database #1285

[lorenzo]

Depends on #1068

[jneira]

• Not sure about handling (download if possible) cabal (or stack?) see my comment:stack install.hs build-all installs cabal in $HOME/.local/bin #1327 (comment)
  • Stack could work out-of-the-box in some cases but it takes a long time while downloading ghc, etc
  • Anyway i would like that hie would be agnostic about build tools
• Likely the setup will change partially when hie-bios replaces cabal-helper, maybe this should wait for it
• Related with hoogle db: HIE should generate local Hoogle database #1285

[NickSeagull]

@jneira I also agree that HIE should be build tool agnostic, but if we chose for the user that doesn't care we'd gain a lot of UX there.

For example, as a user that wants to try Haskell for the first time, and I'm coming from a Java background, I'm probably gonna look for an IDE and let it create the project for me.

Do I use Stack? Cabal? Nix?
I don't care, I just want to make a Hello World and perhaps a factorial afterwards. If the tooling feels good and the language too, I'll probably start learning afterwards.

Furthermore, if we did that tradeoff, HIE could even do stuff like:

You are importing `Data.Text`, which usually comes from the `text` package.
It is not on your project dependencies, do you want me to add it?

I think that a build tool should be completely transparent for the user, if they do not desire to use it directly. I.e.: IntelliJ will behave the same with Maven and with Gradle

[fendor]

Choosing for the user that doesnt care is kind of difficult, since the main target audience does indeed care about it.
Also, I dont think that is something we have to support here. Once hie is relatively stable, it should be possible to offer different flavours of it, if there is a real use-case. E.g. we can add plugins that do what you are proposing, or implement these features in the vscode plugin.

Regarding Data.Text, that is already supported, if a package is unknown, you can add it to your package.yaml or *.cabal file via a code-action.

[NickSeagull]

I'm not saying that we should stop doing what we are doing, but rather provide an option for the newcomers. Having a sensible default always helps.

While I agree that it is not a core part of HIE and should be something apart, like a plugin, or part of the VS Code extension, I think that we shouldn't lose the focus of new users. In the end, some of them transform into contributors, which is always good for the project.

[Xunjin]

Gonna leave my impressions and opinions as a "newcomer" to Haskell and tried (with success now) HIE:

My first contact with this extension was through VSCode at the extension tab, following there the instructions to install was pretty simple:

$ git clone https://github.com/haskell/haskell-ide-engine --recursive $ cd haskell-ide-engine && ./install.hs build-all

At principle i was pretty happy waiting the process to finish, tho after one hour i looked at the terminal and saw that the process still running and looked it installing hie-8.4.4, that sounded an alert on me like:

"Why the hell it is installing 8.4.4 if my ghcup is set to use ghc 8.6.5?"

After that looked my home directory (fresh Fedora KDE 30 install) and observe that the HIE was taking about 15~16 GiBs, then i stopped the process and came to HIE repo to read some docs and procedures about it, reading carefully learnt that the procedure, pointed at VSCode extension page, install all HIE versions (not what i wanted).

So decided to try the ArchLinux Install option (a lot of friends recommended the Distro, why not?) at the end, after suffering (a little) going through the process of installing ArchLinux (now my main distro, quite like it after all 😅), the Arch option does the same as build-all.

Looking at the available options, again 😸, decided to go to Nix and i was quite happy using the nix-env installation (not building anymore, just downloading) at the end was able choose the specific versions of HIE that i wanted (8.6.5 - 8.4.3).

My point in all that is, as @NickSeagull pointed HIE is not that simple to newcomers and can be really a "pain" to go through all of that just to have a LSP IDE like stuff, just yesterday i learnt how much hlint is useful for someone learning Haskell (and not set as default option?! i might be wrong on that).

Comparing to Python LSP by Microsoft (i now it's not really fair to compare), i just had to install point out which python version i wanna use it and it's done.

Hope this bring some light on how HIE feels to a newcomer.

[NickSeagull]

Thanks for the indepth explanation @Xunjin !

Yes, this is what I actually mean. When one programs for a while in a programming language, a "pain endurance" is developed. In projects like this, we really have to make an effort and figure out what's best for new users, given their pain endurance is very low 😊

[fendor]

@Xunjin thanks for sharing your experience!

By the way, hlint is supported in HIE by default. If it is not, that is a problem with the arch-linux installation process.

[Xunjin]

@fendor Ohh sorry forgot to add that today i use the installation option from source (tried the arch-linux which install all versions of HIE) my process, today (which works fine), is pretty simple:

stack ./install.hs hie-8.6.5
stack ./install.hs hie-8.4.3
stack ./install.hs build-data

Then i add the custom configs to match the project as explained in the ReadMe:

"languageServerHaskell.useCustomHieWrapper": true,
"languageServerHaskell.useCustomHieWrapperPath": "hie-wrapper",

My question about hlint, just to clarify, is that hlint is enabled by default?!

EDIT: just found out, i guess, that is enabled by default at the file /haskell-ide-engine/hie-plugin-api/Haskell/Ide/Engine/Config.hs:

data Config =
  Config
    { hlintOn                     :: Bool
    , diagnosticsOnChange         :: Bool
    , maxNumberOfProblems         :: Int
    , diagnosticsDebounceDuration :: Int
    , liquidOn                    :: Bool
    , completionSnippetsOn        :: Bool
    , formatOnImportOn            :: Bool
    , formattingProvider          :: T.Text
    } deriving (Show,Eq)

instance Default Config where
  def = Config
    { hlintOn                     = True
    , diagnosticsOnChange         = True
    , maxNumberOfProblems         = 100
    , diagnosticsDebounceDuration = 350000
    , liquidOn                    = False
    , completionSnippetsOn        = True
    , formatOnImportOn            = True
    , formattingProvider          = "brittany"
    }

[fendor]

Yeah, by default it is enabled and should report problems.
If it does not work, could you please open an issue supplying all relevant information, such as stack version, cabal version, and stderr of HIE, installation process and so on?

[Anrock]

build-all is cancer, we should at least remove it from all manuals. People are always running it and then complain about long build time and huge space consumption

[Xunjin]

@fendor Sure, now it's working flawlessly (at least in my POV) so i don't see the need now, maybe was a missing configuration by my side which no longer exist, or even better, just because i learnt a few days ago about how important hlint is now i'm seeing it's "full potential". Ty for the tip and help 😉

@Anrock that would be, IMHO, the first big step on an easier setup to newcomers. As @NickSeagull commented, newcomers don't have the pain tolerance like a more experienced one, going further on that, we should at least provide a common/recommended "ground" at the docs on how to install properly and easy on most used code editors by newcomers (like VSCode, Atom, Sublime), as the issues #1068 #1327 #1285 are being resolved.

[Anrock]

@Xunjin I've removed build-all mentions from hie readme some time ago already, just didn't know it is still mentioned in readmes of specific plugins.

[Delli]

https://hub.zhox.com/posts/introducing-haskell-dev/ - The easiest way to setup a Haskell environment on Windows

if hie binaries on windows can be combined with the setup above this looks like a dream to me ?

what is de current status of hie binaries on win 10 ? ( and or issue #1068 )
what is currently the best way forward on win 10 ?

[fendor]

@Delli It looks like we are pretty close, it seems like one of the last blocking issue is to change the brittany plugin to use the correct API.