Skip to content
This repository has been archived by the owner on Oct 7, 2020. It is now read-only.

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

Open
Avi-D-coder opened this issue Oct 18, 2019 · 16 comments

Comments

@Avi-D-coder
Copy link
Collaborator

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
Copy link
Collaborator

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

@alanz
Copy link
Collaborator

alanz commented Jan 1, 2020

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
Copy link
Collaborator

alanz commented Jan 25, 2020

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
Copy link
Member

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
Copy link
Collaborator

alanz commented Jan 25, 2020

https://github.com/haskell/ide

Anyone needing/wanting to be a collaborator, shout

@serras
Copy link

serras commented Jan 25, 2020

I am willing to help!

@alanz
Copy link
Collaborator

alanz commented Jan 25, 2020

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
Copy link
Collaborator Author

I am also interested in helping

@EncodePanda
Copy link
Contributor

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

@alanz
Copy link
Collaborator

alanz commented Jan 26, 2020

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

@lukasz-golebiewski
Copy link
Member

I'd love to join the effort! :)

@jneira
Copy link
Member

jneira commented Jan 27, 2020

@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
Copy link

@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
Copy link
Collaborator

alanz commented Jan 27, 2020

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
Copy link
Collaborator

fendor commented Jan 27, 2020

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
Copy link
Member

jneira commented Jan 27, 2020

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.

@jneira jneira changed the title Should ghcide be integrated? Should ghcide be integrated? Yes! see https://github.com/haskell/ide Jan 28, 2020
@fendor fendor changed the title Should ghcide be integrated? Yes! see https://github.com/haskell/ide Should ghcide be integrated? Yes! see https://github.com/haskell/haskell-language-server Apr 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants