search

haskell / haskell-ide-engine

The engine for haskell ide-integration. Not an IDE
BSD 3-Clause "New" or "Revised" License
2.38k stars 209 forks source link

HIE bursts into flames every time I upgrade GHC #1718

Closed raxod502 closed 4 years ago

raxod502 commented 4 years ago

It seems like the way HIE is designed currently, every time I upgrade GHC (on Manjaro Linux), HIE immediately stops working, and it's often impossible to get it working again because (1) downgrading GHC is not practical without a full system rollback, which is not always an option, and (2) even if I edit the PKGBUILD to add support for the new GHC version, it seems that a specific YAML file must be included for every GHC version, so the build fails.

This is really, really bad user experience. Why does HIE need to treat even patch releases of GHC as breaking changes? And how can I work around the problem as a poor user who just wants his Haskell autocompletions to work? To be concrete: currently the latest release of GHC is 8.8.3, but the latest supported version by HIE is 8.8.2. How can I get things running again?

Am I missing something really obvious about how HIE/Stack/GHC are supposed to work? If so, I apologize. The concept of a piece of software becoming completely nonfunctional due to a patch release is foreign to me.

mpickering commented 4 years ago

Build products produced by different GHC versions (including patch releases) are incompatible. It is nothing in particular to do with haskell-ide-engine. You have to build haskell-ide-engine with the same version as you use for your project. There is no way around this and there likely never will be.

I would advise that you don't upgrade GHC until all the projects you depend on support it.

raxod502 commented 4 years ago

I am sorry, but in a rolling-release distribution, it is not really feasible to pin GHC (or at least the last time I tried it, I started getting dynamic linker errors everywhere). I am fine with needing to rebuild haskell-ide-engine with the new version of GHC (although it's not ideal), but the build has to actually work -- and it doesn't currently work. Why cannot haskell-ide-engine use a build system that does not need a .yaml file to be manually created for each patch release of GHC? Does GHC make breaking changes on every patch release beyond simple binary incompatibility, or is there some other reason that manual intervention is required?

Or perhaps alternatively there is some way to tell haskell-ide-engine to use an older (supported) version of GHC via Stack? If so, it would be phenomenal if this important requirement for using haskell-ide-engine were documented prominently, as the out-of-the-box default doesn't work at all.

If my comment comes across as inconsiderate, I am sorry; that is not my intent. I understand that this is a complex project which must suit many purposes and interface with many existing tools. I also understand that it may be that solving the problem I have highlighted would be extremely difficult, and that you as maintainers would prefer to focus on lower-hanging fruit. However, I think it is important to point out that there is a problem, and it's quite bad in terms of user experience (keeping in mind that user experience is largely proportional to adoption of haskell-ide-engine). Even if the problem will not be solved anytime soon.

To other users of haskell-ide-engine: luckily, there is a workaround. Simply build branch ghc-8.8.3 from fork jneira/haskell-ide-engine. On Manjaro Linux, this can be done by editing the PKGBUILD for haskell-ide-engine-git as follows:

mpickering commented 4 years ago

I am sure we could help you in some way but the tone of your issue is not an acceptable way to communicate on an open-source project. What you must understand is that there are many different users with different requirements, and the fact that things do not work perfectly on your environment is not an indication of some fundamental breakage. In this particular case, I suspect the decision taken by arch to only distribute dynamically linked libraries is causing you some of the issues you describe and this decision was taken against the advice of the Haskell community.

If you wish to open a new issue with a more constructive tone then perhaps we can go from there.

raxod502 commented 4 years ago

I apologize for offending you. If I understand correctly, what bothered you about my comments was that I made the claim that the behavior in this issue report is a problem in HIE. I can sympathize; it can be annoying when somebody else makes claims about something they don't have complete knowledge of. If there is something else that you found objectionable about my comments, please let me know and I would be happy to try to improve. I certainly don't want to be rude.

In any case, since you requested that I create a new issue, that is what I will do.

lspitzner commented 4 years ago

@mpickering have a bit of patience with the poor haskell devs on arch-based distros :)

in a rolling-release distribution, it is not really feasible to pin GHC

Wrong! I have "pinned" 8.0, through 8.8 (installed in parallel of course) simply by not using the archlinux distro packages, without any issues. That is, I use GHC binary releases, put that on PATH, done. I have not seen linker errors from that.

This is advisable in general ever since https://old.reddit.com/r/archlinux/comments/7hanz7/whats_the_current_state_of_haskell_on_arch/. Not sure about the exact state of things on manjaro, but I expect it to apply.

And I would claim the opposite: When doing development, depending on a rolling-release dev environment is not feasible. Expecting support for that is a tall order.

And once you realise that even that kind of setup is too dynamic, feel free to try nix(os).

raxod502 commented 4 years ago

See https://github.com/haskell/haskell-ide-engine/issues/1721#issuecomment-609847125 for how I solved the issue.