Option to automatically build ghc-mod and hlint inside Stack-based projects

[varosi]

I have written about that elsewhere, but this is what EclipseFP was doing before in Eclipse for cabal-based projects into a sandbox. It think that this will help with easier use of atom-haskell and closer to "just works" concept. If we're using multiple projects inside same Atom editor - it could use different ghc-mod executables for each project depending on its stack resolver. Currently I do this by hand each time outside Atom.

[lierdakil]

Recent enough versions of stack (tested with 1.1.2) should generally install ghc-mod into snapshot. So, in general, you should only need to do this once per resolver. Unless you update to nightlies daily (which doesn't sound good), it should be bearable.

Automatic builds come with a lot of caveats, I say that from my (admittedly limited) experience with SublimeHaskell plugin, which attempts (or at least attempted) to build ghc-mod automatically. Suffice to say, it didn't work all that well.

There's also an issue of newcomers to Haskell. Long story short, if ghc-mod would fail to build automatically, it would be a nightmare to debug this with someone who has a very vague idea of what's going on. Current setup process, while cumbersome, at least makes this explicit.

Lastly, it's really hard to judge user intent w.r.t. stack vs cabal without explicit user input.

What I'm trying to say is, this kind of thing is really, really hard to get right. And between fragmented PATH settings in ide-haskell packages and ghc-8 support I really don't think I can spare the kind of time and thought this really needs right now.

PRs are welcome, but for now this is "wontfix".

2016-06-15 16:27 GMT+03:00 varosi notifications@github.com:

I have written about that elsewhere, but this is what EclipseFP was doing before in Eclipse for cabal-based projects into a sandbox. It think that this will help with easier use of atom-haskell and closer to "just works" concept. If we're using multiple projects inside same Atom editor - it could use different ghc-mod executables for each project depending on its stack resolver. Currently I do this by hand each time outside Atom.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/atom-haskell/haskell-ghc-mod/issues/159, or mute the thread https://github.com/notifications/unsubscribe/AG8EZhcNYOg8d0rONH-x7aAipClqBJOpks5qL_3UgaJpZM4I2Wuo .

[varosi]

This could be an option to choose. I just want to think in a direction for easy to setup Haskell working environment with a few steps. The ideal case will be "Next...Next...Finish".

Thanks for the full answer on that.

[varosi]

Is it possible to make an option to select custom path to ghc-mod depending on GHC version? I mean if current project is built with GHC 7.10.3 to set path to ghd-mod built with it. If I have project with GHC 8.0.1 to use different path to ghc-mod built with this GHC. This will save me a lot of time of rebuilding ghc-mod when I switch projects. Ideally this should work with multiple Haskell projects folders opened in Atom.

[lierdakil]

I'll see what I can do.

[varosi]

Coool!

[varosi]

This will be great option! It's everyday problem when one works on multiple projects each built with different LTS.

[lierdakil]

Actually, working on different projects should "just work", regardless of resolver used, since ghc-mod is installed into snapshot, so all projects using a given resolver can share it...

[varosi]

Yes, only if it is already installed per project. This is a very common task and it'll be great if it's automated by the IDE.

[varosi]

This feature of Stack could help a lot on that issue - https://github.com/commercialhaskell/intero/issues/324

[varosi]

Other related issue - https://github.com/commercialhaskell/stack/issues/3717

[lierdakil]

Cool. Thanks for the heads-up.

[lierdakil]

So, after God knows how long, this is finally implemented in v2.2.0. Thanks for your patience. In my defense, this became viable only recently due to massive internal changes. And by recently I mean around v2.0.10.

Implementation might be rough around the edges, and is strictly opt-in for now (which will be changed once the feature is tested "in the wild" and most prominent kinks are ironed out)

You can opt-in by enabling this option in h-g-m settings:

A few caveats exist:

• Building ghc-mod is only suggested when you have ide-haskell-cabal, and you have chosen builder to be stack.
• It runs stack --copy-compiler-tool build ghc-mod, so you need recent enough stack. Note this might be somewhat suboptimal, since it won't update ghc-mod if a newer version lands in a new resolver. On another hand, rebuilding ghc-mod on every resolver change doesn't sound like much fun either (although that's exactly what we've been doing for a while now)

When Atom detects version mismatch, it does this:

One rather important thing, from the top of my head, is missing. It doesn't prioritize stack/cabal sandbox depending on chosen builder. In some setups (admittedly, somewhat exotic, both stack.yaml and cabal-sandbox.config, ghc-mod installed into cabal sandbox), this may lead to some frustration.

[varosi]

Great! I have tried it after updating of Atom and plug-ins. But I hit a problem when I deleted ghc-mod installed on PATH. Plug-in failed with:

Haskell-ghc-mod: ghc-mod failed to launch. It is probably missing or misconfigured. ENOENT

i.e. it even does not proposed me to build it. The new option is already enabled. May be it is not executed via stack, like:

stack exec -- ghc-mod ...

[varosi]

It runs stack --copy-compiler-tool build ghc-mod, so you need recent enough stack.

About this problem - stack version could be verified automatically with: stack --version

[lierdakil]

To be clear, did you get 'Failed to check compiler versions' error among other things?

[varosi]

Addition: when I have done:

stack build --copy-compiler-tool ghc-mod

It executed ghc-mod. So the problem is when it is not built at both places.

But later I got:

EXCEPTION: browse: ghc-mod: can't find a package database at C:\stack\snapshots\726bcf65\pkgdb EXCEPTION: info: ghc-mod: can't find a package database at C:\stack\snapshots\726bcf65\pkgdb ghc-mod: ghc-mod: can't find a package database at C:\stack\snapshots\726bcf65\pkgdb EXCEPTION: types:

[varosi]

I don't find any "Failed to check compiler versions" message in the console. It's only that exception message.

[lierdakil]

See if v2.2.2 works any better. Thanks for testing by the way!

[varosi]

Thanks for working on this issue! New version gives the same error. But the error is giving wrong path "C:\stack...". Currently after update to some later Stack it's located under "C:\sr\". So I have deleted .stack-work subfolder and after a long running wait process (where nothing is seen because there were no output during the process - only at the end) it is WORKING!!! Cool! It looks like it built the project from scratch, that is way it was long running process!

[varosi]

Is it possible HLint to be built with ghc-mod, too? It's used in haskell-ghc-mod plug-in and it could be built automatically.

[varosi]

btw, installing of most recent ghc-mod (8.2.2, 8.2.1, 8.0.2, 8.0.1) could happen on plug-in install time as people expect there to be lost most of installing time. But it's just a proposition.

[varosi]

I'm testing here at different projects and it's working very well! It's one of the best and useful features of haskell-ghc-mod!

[lierdakil]

Is it possible HLint to be built with ghc-mod, too? It's used in haskell-ghc-mod plug-in and it could be built automatically.

It's a dependency of ghc-mod. Hence, it's built anyway. And h-g-m doesn't call the binary directly.

[varosi]

Okay, great!