Add support for GHC-9.2.3 #2985
Comments
Kindly explain how I can compile/install HLS using ghcup. I'd rather not build it myself directly from the source (aka, clone the repo myself and build with Cabal or such). What input do I provide to
I know what GHC versions I want to compile it for - but what Here's what
Please reconsider. Among multiple reasons for doing so, many people manage their Haskell platform installations via UpdateAttempting to use |
|
cc @hasufell , maybe we can document this in ghcup more clearly? |
|
|
Thank you! Command provided by @hasufell seems to work, though I observe some strange errors: One issue seems to be the Perhaps, this could shed some light? It appears that the offending attribute is not set/present there? Second concern is this statement in the output: Is it trying to actually build the master, or v1.7.0.0? Lastly, perhaps @hasufell could tell how I could instruct |
Update: no joyBuilding master failed miserably. On one machine (both are Macs, run the same version of MacOS 12.4, and have the same Haskell stuff installed (Cabal, Stack, GHC, ghcup, etc.)): Another machine (very similar output): Which makes me repeat my request: please release HLS binary that supports GHC-9.2.3. |
You only need to build for the GHC you're missing. There's no point to build the others.
See For the build failure look into |
Understood, thanks!
My problem is - I don't understand what to actually put in place of
Can you confirm that it is trying to actually build the master, and not v1.7.0.0?
|
|
@hasufell your suggestion to build only for 9.2.3 worked, thank you: |
|
Just curious, why not release new binaries, @michaelpj? When would you roughly expect a new release? I'd love to get my team fully switched over to GHC 9.2.3, but it can be a bit frustrating to get all of them to compile it. There are often subtleties with using ghcup to compile hls, I've found. Maybe that's all been fixed. It'd be a lot easier if there were a new release. Thanks for all your hard work! |
|
Doing a release is currently a fair amount of work, someone needs to step up to do it. We don't have a release schedule largely because we're low on people who are willing to do the release work. |
|
Thanks @michaelpj for the insight. We'd be happy to pitch in to help with the release work if you think that makes sense. HLS is an amazing project and totally critical for us. Is there a document or something you could point me to for me to understand what's involved? btw, @hasufell, your suggestion did not work. I needed to point it at master to get it to compile. Then even if it compiles, there's no guarantee that it'll work. I might have to just compile from your repository without ghcup. I'll report back. $ ghcup compile hls -j 14 -v 1.7.0.0 --ghc 9.2.3
[ Info ] downloading: https://downloads.haskell.org/~hls/haskell-language-server-1.7.0.0/haskell-language-server-1.7.0.0-src.tar.gz as file /tmp/ghcup-d0cab68807a3b970/haskell-language-server-1.7.0.0-src.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5546k 100 5546k 0 0 3274k 0 0:00:01 0:00:01 --:--:-- 3273k
[ Info ] verifying digest of: haskell-language-server-1.7.0.0-src.tar.gz
[ Info ] Unpacking: haskell-language-server-1.7.0.0-src.tar.gz to /tmp/ghcup-6ac82875ea639f5c
[ Info ] Building HLS 1.7.0.0 for GHC version 9.2.3
[ cabal ] base-3.0.3.1 (constraint from non-upgradeable package requires installed
[ cabal ] instance)
[ cabal ] [__2] fail (backjumping, conflict set: base, ghcide, hiedb)
[ cabal ] After searching the rest of the dependency tree exhaustively, these were the
[ cabal ] goals I've had most trouble fulfilling: base, ghcide, hiedb
[ cabal ]
[ Error ] BuildFailed failed in dir /tmp/ghcup-6ac82875ea639f5c/haskell-language-server-1.7.0.0: Process "cabal" with arguments ["v2-install",
[ ... ] "-w",
[ ... ] "ghc-9.2.3",
[ ... ] "--install-method=copy",
[ ... ] "--jobs=14",
[ ... ] "--overwrite-policy=always",
[ ... ] "--disable-profiling",
[ ... ] "--disable-tests",
[ ... ] "--installdir=/tmp/ghcup-6ac82875ea639f5c/haskell-language-server-1.7.0.0/out/9.2.3",
[ ... ] "--project-file=cabal.project",
[ ... ] "exe:haskell-language-server",
[ ... ] "exe:haskell-language-server-wrapper"] failed with exit code 1.This is why I'm kind of hesitant to tell my company to compile it. It's actually kind of subtle to get it all to work right. Thanks again for your help. |
I'm not sure I understand. It compiled from master and runs, but you're not sure "it works"? |
It is possible for a thing to compile and not actually function as intended. This has happened to me with ghcup-compiled HLS in the past! I've compiled using ghcup, and then HLS just can't load anything properly. If I compiled out of a manually cloned repository, which I'm sure is slightly different than how ghcup is compiling it (probably different compiler flags, or a different compiler version, or something), then it often works straightforwardly. It seems those issues have been resolved. I tested the ghcup-compiled with GHC 9.2.3 on master. It seems to work. Thanks for your help. |
|
After it works ok. |
|
It's simple. So, trying to build HLS 1.7.0.0 with GHC-9.2.3 is bound to fail. But building HLS with |
Yes, because what else is it supposed to do? Come up with its own imaginary version?
Yes, because it is 1.7.0.0. There is only one place you can define a project version in Haskell: the cabal file. If you take a look at if you please so. |
Well, I can't tell you what your programs should do, but, in my opinion, when That IMHO would be better than either guessing the version (which doesn't exist yet - you can't know if the next release would be 1.7.1.0, or 1.8.0.0, or whatever), or falsely reporting a version that the code does not correspond to (to prove this fact, compare the results of building "-v 1.7.0.0" and "-g master", and explain why they differ, even though both are reported by
In theory - perhaps. In practice - I haven't seen any package whose Version field of cabal file actually tracked every commit and such. When the release is locked, this field is adjusted, and then usually left alone until the next release is ready. Which makes relying on this field for anything between-releases unreliable at best. |
If you read the output, it does exactly that: It even tells you twice:
What is unclear about this? Yes, we could additionally dereference
This is not a solution. We're extracting the version, because we need a version so that we can name the binaries correctly. Or do you want to have binaries named:
This would create an insane mess in
We're not falsely reporting anything. We're reporting whatever the maintainers have set the version as. Use the You really haven't given an alternative approach here. |
Maybe the above is clear to you. To me it's confusing, because "Git version master" at this point is neither 1.7.0.0, nor 1.x.x.x. But I'm afraid we'd have to agree to disagree here. We don't seem to understand each other's points.
There are two issues - naming the binaries and reporting what actual version those binaries correspond to. I claim that you're probably right regarding the first part, but not - with the second...
Strictly speaking, In most of the packages I've dealt with, executables build from between-the-releases Git code respond to
I cannot argue with you here, as I don't have sufficient appreciation of what's involved.
Haskell released programs follow PVP, or at least should. My point is that there's no valid PVP for a between-the-releases code snapshot, and commit hash is the closest to its unique identification.
I tried to explain why what the maintainers have set does not apply in these cases.
Thanks. I did not think of this option. What are the consequences of using it, e.g., specifying
I wish I knew a simple all-satisfying all-encompassing alternative. As I said, in other projects - those few that I (co-)maintain and those many that I use - usually binaries report their versions as In one case (asn1c), my code reports the previously-released version, even though the code moved away from it far enough. The main reason is - I couldn't figure how to make it report the current commit level within the time I could afford to spend on it. And users that requested that it reported "dirty" snapshots at the commit level, couldn't provide a PR that I would use. I guess we're in a similar situation here - I can't provide a PR for you that would accomplish the goal. :-( |
ghcup allows this (I think), but will treat it differently in certain circumstances, because it's not a valid PVP version. |
Is this the sort of thing the Haskell foundation can help with? It seems like automating the production of release binaries would be a huge win. New GHC releases are frequent and not being able to use them means they're not getting the testing they deserve. It's not reasonable to expect volunteers to do drudge toil every time there's a new upstream version bump. |
I guess they can pay someone, but then you either need the company of the employee to approve or engage people who are freelancers (I'm available until 27 july). Although there's a full time devops now working on GitLab GHC CI, I'm not sure this would be within scope of that position. I'm also a bit worried it would lead to everything nixified, which would be bad for the bus factor. Good releases can't be fully automated. You need to talk to people, clear some dust, do manual testing. |
Yes, maybe too frequent and they put a lot of work on packagers. I had to fix around 20 bindists (unpack, fix Makefile, repack, upload, update hashes and URLs in ghcup metadata), because of a GHC build system bug for the next ghcup release. Luckily, many LSP installers, like vscode-haskell and nvim-lsp-installer use ghcup, so any work on HLS bindists at least isn't duplicated. This is just my opinion, but I really think installing HLS from source should be a good option and be made as easy as possible. I can imagine adding a command in vscode-haskell to do that automatically in case the pre-packaged binaries are not sufficient. |
|
For some context, we have been working on getting our Haskell code upgraded to the latest GHC, or near enough. For those unfamiliar with Stack, the version of the Haskell compiler we get is specified in the "snapshot" we point to with the resolver field in the stack.yaml file. For the two current stable branches:
The trouble is that GHC 9.0 was widely viewed as a dud; there are too many bugs and upstream has moved on already. Which is great! but there's not yet a "stable" snapshot with GHC 9.2, but it is what's on the "nightly" one.
Which would be great except that as we've been discussing haskell-language-server doesn't support GHC 9.2.3 yet (so be it; this is open source. We gratefully accept the generous contributions of all concerned). I did some experimenting and tried something that's been there almost since the beginning of Stack but that I've never tried before: you can specify a different compiler. This is what I put in a given project's stack.yaml: Ordinarily you wouldn't do that because the whole point of a Stackage snapshot is that it's a set of packages that are known to build together—and the most fundamental of those packages are the ones from base & friends which are shipped with GHC, not downloaded separately from Hackage. But I took a punt, on the presumption that in essence nothing in base et al would have changed irredeemably between 9.2.2 and 9.2.3. It worked; the HLS brought in by VSCode is doing its thing. So this is a workaround. This really isn't a good idea in anything other than the short term, because as mentioned drift between what's been qualified in Stackage CI and the libraries supplied by the compiler will very shortly become irreconcilable. But this buys a little time for the people generously working on HLS to be able to get a release out that supports GHC 9.2.3. |
This doesn't scale well. My team is only 12 engineers, and I spent a good deal of my time last week fixing everyone's problems related to upgrading HLS via compiling from source. I could not predict all of the issues. Trying to get 12 people to compile something, especially without an official release, is very painful. There's lots of weird issues on everyone's machines that you wouldn't expect. I tried to make it as absolutely clear as possible what to do, but it doesn't work out as you plan, especially for a project as complicated as HLS. I agree it should be a good option to compile from source, but the reality is that it's quite complicated in practice. I completely echo @istathar's points. We are in exactly the same situation and made a very similar decision. We're willing to help here! I think it'd be amazing to try to get the Haskell Foundation involved. |
|
@wraithm I'm not sure I follow. I'll be the first to say that we need official release of the HLS that supports GHC-9.2.3, but I found no difficulty (after the process was explained here 😉) making Basically, all I needed was to specify I did not want to use 9.2.2 (it has bugs, many of which 9.2.3 fixes), nor 9.0.x - for reasons brought up by others. At this point, HLS master works reasonably well with 9.2.3. |
The point is that we're all relying on the automation to download a toolchain (which includes editor support) for everyone on a team so that no one has to think about it. If we have to tell everyone to "stop what you're doing, manually build the language server, install it in the proper place [good luck with that], and configure your IDE to use it" it's a big ask times n people. And it's absolutely impossible for members of the team who are new to Haskell. Now, that's not on the HLS contributors to resolve, but we've set a high bar across the Haskell ecosystem. The last couple of years have been amazing, with the VSCode Haskell extension downloading the prebuilt language server automatically; with Stack and GHCup bringing prebuilt compilers in automatically, with Stackage giving us sets of packages that actually build together ... it all Just Working™ and it's awesome. Since this has become a critical part of the workflow of so many of us, we're asking how we can help (but also asking how we can make the problem go away). I'm funding getting Stack upgraded to fully support 9.2.x, hopefully others can step in to see HLS get the help in needs too. Please let us know what's needed. |
Yes, I already explained this here haskellfoundation/tech-proposals#16 (comment) My suggestion is to use cabal with stackage.
Well, not really. PVP guarantees backwards compatibility and from what I know there are no major PVP bumps within a major GHC release. E.g. GHC-8.10.1 ships with base-4.14.0.0 and GHC-8.10.7 ships with base-4.14.3.0. PVP demands that there must be no API breaking changes between those base versions. The story might be a little different if you depend on the ghc API itself.
Well, we can't improve ghcup or HLS compilation if you don't submit bug reports about what went wrong while compiling HLS.
Again: this is automated via: Adding GHC-9.2.3 pre-built bindists is fine too. But I'd also like to improve the ad-hoc compilation so that we have less pressure on constantly working on bindists, CI etc. |
@istathar sorry, the above is absolutely not what I'm observing:
|
|
@hasufell, the issues we ran into are not bugs. It's just people having weird cabal setups on their machines, or forgetting to do As I said, I tried to give clear instructions with a script, but it's not that simple. Also, it took me a while to figure out exactly what the right command was to get this to work. For example, I didn't even have them do We're offering to help! I don't understand why there's something wrong with offers of help to do releases. If we had binary releases, I would have several hours back of my and many others' time. |
I certainly won't. But I sense that you're not interested to report user experiences. That makes my life difficult. E.g. I just created a PR to improve various things in
Yes, we're trying to improve the documentation on this as well: #3004
I think we made clear that we do accept help with releases and are planning to do an update. But it's not the only direction that needs work to make things better. |
|
I have a good experience with compiling HLS directly from Hackage: From my perspective it is easier than search for bindists, and recompilation does not take long, because it leverages all normal Cabal caching mechanisms. Compilation from the repo (as |
I'm not sure I follow. We use In addition, pinned index state reduces recompilation, it doesn't increase it. If you want to ignore the index state from the |
|
I don't understand @Bodigrim point. The main reason to compile HLS from source IMHO is to get patches that haven't made it to Hackage (yet). I assume that pushing sources to Hackage coincides with a new binary release? |
|
@mouse07410 there is no binary release of HLS for GHC 9.2.3, but you can grab already released packages for HLS 1.7 from Hackage and compile them yourself. You don't even need |
|
True... users have these options:
I mean, we could certainly add more documentation about all those. But is it really that difficult? |
|
Thinking about @Bodigrim's comment, there's one main advantage of hackage dist: in-place updates of version bounds. I remember getting odd errors with PR to add support for building from hackage: https://gitlab.haskell.org/haskell/ghcup-hs/-/merge_requests/268 |
|
Does it mean that building fur the latest GHC compiler would still be better from the GitHub master? Because there's probably more to compiling a working HLS than having the bounds adjusted? |
Ailrun
added
GHC
|
There have been major improvements about the Documentation here:
E.g. ghcup compile hls --git-ref master --git-describe-version --ghc 8.10.7 --ghc 9.2.4 --cabal-update |
Is your feature request related to a problem? Please describe.
In the GHC 9.2 realm, GHC-9.2.3 was released, among other reasons to fix bugs introduced in 9.2.2. It is currently very inconvenient to use 9.2.3 with an IDE, because with HLS services unavailable - IDE becomes little more than a dumb editor. This forces users to either abandon 9.2.+ features, or lose the help of HLS. Neither alternative is nice.
Describe the solution you'd like
There already is partial support in HLS for 9.2.2. I'd like to see at least partial support for 9.2.3 released ASAP. If the choice is between improving support for 9.2.2 and enabling 9.2.3 - IMHO, 9.2.3 wins hands down.
In other words: please prioritize adding partial support for 9.2.3 over improving generic 9.2 handling.
Describe alternatives you've considered
The are two alternatives: use 9.2.3 without HLS support, or use HLS with 9.0.2 (9.2.2 is not a preferred choice).
The text was updated successfully, but these errors were encountered: