Should ghcide be integrated? Yes! see https://github.com/haskell/haskell-language-server

[Avi-D-coder]

ghcide's errors reporting, hover, goto definition is far more fault tolerant. It still works when started in a file with errors. It is also very snappy. I would argue that hie should fully integrate ghcide.

What do other people think? Are there any fundamental problems with relying on it?

[mpickering]

The plan is to merge in the hie-bios branch then look into integrating ghcide.

[alanz]

See also #1525, as a background info issue.

The current plan is to work on this at Bristol Haskell Hackathon 2020, kindly arranged my @mpickering .

[alanz]

Our preliminary discussion at the Bristol Hackathon is that we will create a new umbrella repo, aiming to be called github.com/haskell/ide, which will make use of libraries from ghcide, haskell-ide-engine, and whatever else makes sense. It should be a quite small application, forming an integration point.

The main interface to ghc will be via ghcide, which has a demand-driven shake based build system, also using hie-bios at the bottom.

The initial work will be about making sure ghcide supports multi-modules, and that hie-bios has good implicit-project support, probably making use of cabal-helper.

The plugin format will be harmonised, the goal being to be able to create a main haskell file which imports dependencies from hackage, puts them in a structure and launches the LSP server with them, that just works. This means for example that formatters can be pluggable, and you only need to build the one you intend using. It should also allow configuring in private plugins.

[hasufell]

which will make use of libraries from ghcide, haskell-ide-engine, and whatever else makes sense. It should be a quite small application, forming an integration point.

What is the proposed workflow of the joint project? What are the project goals? Will legacy code be dropped? Will there be feature regression tests?

IMO, a big part of tooling problems arise from the fact that codebases quickly become unmaintainable and inaccessible to contributors, because they are inherently difficult problems. That's even more a reason to be particularly worried about maintenance and project policies.

probably making use of cabal-helper

Isn't cabal-helper one of the more problematic parts of the toolchain? It compiles things at runtime in my home directory somewhere and regularly fails.

[alanz]

https://github.com/haskell/ide

Anyone needing/wanting to be a collaborator, shout

[serras]

I am willing to help!

[alanz]

I am willing to help!

And it seems I need permissions tweaked on the repo to be able to invite collaborators. Will get it sorted tomorrow.

[Avi-D-coder]

I am also interested in helping

[EncodePanda]

Count me in to pick up all the low hanging fruits :)

[alanz]

I just invited @serras , @Avi-D-coder and @EncodePanda to be collaborators

[lukasz-golebiewski]

I'd love to join the effort! :)

[jneira]

@hasufell

What is the proposed workflow of the joint project? What are the project goals? Will legacy code be dropped? Will there be feature regression tests?

I think the integration is in a very early step and that info is not clear or definitive yet (but the points made by @alanz in hie comment). Sure it will be included in issues and/or prs in the new repo: https://github.com/haskell/ide

Isn't cabal-helper one of the more problematic parts of the toolchain? It compiles things at runtime in my home directory somewhere and regularly fails.

I agree that compile at runtime is a moving piece that has more chances to fail but it tries to resolve a somewhat hard scenario: cabal-helper has to read the setup-config data generated by cabal (directly or via stack) and that data depends heavily on the Cabal library version. So cabal-helper compiles at runtime the program that reads setup-config, linking it with the appropiate Cabal library version for the project at hand (maybe @DanielG could correct me if i am wrong).

In fact the starting idea to handle plugins in the new project is to compile them at runtime so it will be a necessary step, not only isolated to cabal-helper.

However maybe there could be other alternatives, they could be discussed in the new repo.

[ndmitchell]

@hasufell details on the workflow at https://neilmitchell.blogspot.com/2020/01/one-haskell-ide-to-rule-them-all.html. We want a good IDE for Haskell. We want it to be well written - which is why we're moving to a new architecture we think is better for reducing the complexity. We want to segregate things like cabal-helper behind nice API's, which is what is being done with hie-bios. It sounds like what you're asking is will there be a focus on quality? Definitely, yes :)

[alanz]

In terms of releases etc, I think we should continue the monthly hie release cycle, until such time as we are happy that haskell-ide is equivalent or better.

I am open for discussion around this though. And it may be more maintenance stuff than major feature addition.

[fendor]

I am also in favour of maintaining monthly releases. Especially in this month, a lot has happened and I estimate that users will still use the same tools for the next months.

[jneira]

In terms of releases etc, I think we should continue the monthly hie release cycle, until such time as we are happy that haskell-ide is equivalent or better.

I am open for discussion around this though. And it may be more maintenance stuff than major feature addition.

Agree, maybe a visible note with just that info in readme would be useful for users and new contributors.