HLS 2.5.0.0 #159
HLS 2.5.0.0 #159
Conversation
You mean HLS devs broke building against GHC 9.0.2? |
|
https://github.com/haskell/ghcup-metadata/actions/runs/7004533883/job/19052479590 Fedora build should be updated to Fedora 37, so we can verify on later Fedora. |
No, we dropped 9.0.2 support explicitly. the bindist job refuses to be started: https://cirrus-ci.com/task/6385995852021760 |
That job was auto-cancelled, because you force pushed to your PR. Can you show the actual failure? |
I didn't force push, to update the PR and rerun the release jobs I have to push the PR and force push the tag. Both the tag and the PR are on exactly the same commit. Apparently this confuses cirrus CI so it refuses to run the job. When we added FreeBSD builds, it was understood that it was on a best-effort basis. If this is not satisfactory, unofficial bindists can be uploaded. |
|
Updated the fedora job: https://github.com/haskell/ghcup-metadata/actions/runs/7005128652 |
I don't think GHCup developers ever agreed to that. There are unofficial GHC bindists for FreeBSD for 9.2.8 and 9.4.5 from @arrowd. We can add those to GHCup and rerun the Cirrus CI. If HLS release manager does not want to do that, then please drop HLS 2.5.0.0 from |
What is the rationale behind dropping it from the default yamls? They can always be updated later if additional builds are provided. |
It's bad form to add things later, especially since we set this release as I am building those missing GHC FreeBSD bindists now. |
|
9.4.7 was the recommended GHC version but it had no FreeBSD bindists. |
Exactly. I'm building bindists for 9.4.8 and 9.6.3 now. |
|
If we can add FreeBSD bindists for GHC after other bindists have already been merged, then I don't understand why the same issue is a blocker for HLS bindists. FreeBSD bindists for HLS can be added after this PR is merged. |
Yes, technically it can, but I don't support upstream release managers supplying half the work (except for the vanilla channel, which is solely maintained by you). So if that continues, I will fork the CI and do it on my own. I already do that for cabal. This is up to you. I want to do proper work. I can't always do that, because I don't get paid. Releases should be put out for all platform in lock-step. The fact that we failed to do this for GHC is not a good argument that we should continue this broken workflow, where FreeBSD users have to wonder when |
They will still have to wonder because unofficial FreeBSD bindists (for both HLS and GHC) are untested and unsupported, as has been discussed many times. Neither HLS nor GHC testsuites are run on FreeBSD, and upstream has no way of validating the correctness of any of these distributions. Supporting FreeBSD even when it is explicitly unsupported by upstream is a choice that GHCup makes, and if doing so is not sustainable it should reconsider this decision. |
I don't care whether they're unsupported by upstream. Please see:
and: The solution (as explained in that blog) is to run tests on the end users system and fix the GHC test suite and the GHC test bindists:
The GHC test bindists are busted (and the last few metadata PRs actually added broken links) and the GHC suite is so flaky that this is unfeasible at the moment. That is not my responsibility. That is up to GHC HQ to fix. At that point I may consider running the test suite. You'll have to figure out how to separate building and testing properly. |
|
Julian: I was also under the impression that we agreed to support FreeBSD on a best-effort basis. We added it specifically because you wanted it and because we thought it would be manageable with your support. While you were away, it broke and none of us were able to fix it, so we had to drop it. I'd be okay with it coming back if you're able to help keep the FreeBSD builds working. |
Well, I don't consider this here "best effort". I get a report "Cirrus CI refused to run" and "let's drop it" with no attempts to improve the situation. I am building the last missing GHC bindist 9.8.1 now. If I don't get support from HLS release managers with the missing HLS bindists, I will do this myself and the release will be delayed for the main GHCup distribution channel. The vanilla channel can be updated right now. Going forward, I'm planning to employ stricter policies, since GHCup is getting funded maintainers. |
|
@wz1000 did try to make Cirrus CI work quite a bit. Julian, we are trying to support you. We changed the entire release CI to make things easier for ghcup. But we can't do an infinite amount of work either. We need support in order to support FreeBSD. If you're not willing to work with us on that and you'd rather do it yourself, then I guess you can do that, but it seems less efficient. Yelling at us doesn't help either.
Why is it a problem to add things later? |
Then I should make clear that I have no appetite to discuss whether or not to support FreeBSD and whether or not to ship everything at once or in a piecemeal fashion. This is draining my energy and I don't have a lot of it, so I'll rather focus on the things that I can control. If you want to support my efforts, then use the FreeBSD bindists that I just pushed, update the Cirrus CI to use those and then produce a bindist. FreeBSD now supports 9.2.8, 9.4.8, 9.6.3 and 9.8.1. |
It sounds like you want us to produce FreeBSD bindists because you want to support FreeBSD, but you don't want to help us do it. And also that you won't let us make releases to the GHCup channels unless we do so. Is that right? |
|
Also note: the vanilla channel is maintained by upstream and they can make whatever decisions they please there. Projects are also free to recommend to their users to use the vanilla channel instead of the default channel (e.g. if they think unofficial bindists are bad). How to use those channels is described here: https://github.com/haskell/ghcup-metadata#using-the-metadata |
I just spent two hours building missing GHC binaries. If you want me to do the rest of the work, then that will have to wait. |
|
It would be a shame to switch e.g. the channel used by the VSCode extension. I would rather be using the recommended one. More importantly, that moves us towards a world where more work is being done to produce other bindists, a lot of it by you. That seems bad! |
It frustrates me that, say, dropping a long-abandoned HLS plugin takes months of deliberation and community involvement, but a botched CI job is enough to remove a release platform, abruptly. Please notify both me and Julian next time you run into an issue with Cirrus CI.
And rightfully so. Over the years, observing Julian thanklessly fixing mistakes and shortcomings of release managers, I learned to trust his choices and preferences to maintain quality of the recommended ecosystem, even if it means waiting another week or two. |
I'm sorry, but when we added FreeBSD as a release platform, it was explicitly under the assumption that binaries would be provided on a best effort basis, especially considering that upstream GHC has dropped all support for FreeBSD binaries, and the availability of unofficial binaries is spotty at best. These are the GHC versions that HLS 2.5.0.0 supports: 9.2.8, 9.4.8, 9.6.3 and 9.8.1 No FreeBSD ghc binaries were available when the release was being prepared for any of these versions, official or unofficial. HLS 2.4.0.0 supported GHC 9.0.2, which had official FreeBSD binaries available. Since HLS dropped support for this GHC version, there were no binary distributions available for any of the GHC versions all the other platforms support. FreeBSD CI for HLS is set up to produce binaries for 9.2.5 and 9.2.7, which is both redundant and out of date, so FreeBSD support for HLS was hanging by a very fragile thread even before I decided to drop support completely, instead of delaying the release further for the sake of supporting two unofficial binary distributions of outdated minor GHC versions. Even if these binaries were uploaded with this release, it would have no impact on FreeBSD support for GHC versions recommended by GHCup. I have to note that I have not interacted with a single user depending on these binaries in any way. You can search the HLS issue tracker for mentions of FreeBSD, and there are virtually no reports from actual users: https://github.com/haskell/haskell-language-server/issues?q=is%3Aissue+FreeBSD+ Producing and validating binary distributions is a difficult and thankless job, so we are very thankful to Julian for all he has done in expanding GHC binary coverage unofficially, and validating official GHC and HLS bindists. But we have to come to terms with the reality that one unpaid volunteer cannot maintain support for these platforms alone, and so productive and charitable interactions between release managers and the GHCup maintainer are essential. We have tried to work closely with Julian for the sake of the ecosystem, ensuring metadata updates are prompt, waiting for GHCup to be updated before making release announcements, introducing additional testing and automation on the GHC side for producing binaries and carrying on GHCup metadata maintenance when Julian is not around. We have always also deferred to Julian on his decisions as GHCup maintainer about which versions should be marked as recommended, when when we might not completely agree with these decisions or how they are made. Refusing to merge a release due to missing FreeBSD binaries even when there is no drawback to adding these binaries later is not an example of good faith interaction. Indeed, recently FreeBSD binaries were just added for a whole slew of GHC versions long after initial support for these GHC versions was merged into GHCup. For some further context, when we agreed to produce FreeBSD binaries, it was as part of a long and contentious process where our entire release CI was rewritten, with honest and productive feedback going completely unaddressed and being met by uncompromising demands backed up by threats of non-cooperation. I must note that each of individual, unaddressed objections which were brought forward when we originally switched CI to github has played out exactly how I worried, causing multiple delays for multiple HLS releases. This very release has been delayed for a week because we now depend on a single small aarch64 darwin runner maintained by a volunteer in his free time rather than the suite of aarch64 runners that are constantly tested in GHC Gitlab CI and maintained with the support of the Haskell Foundation. At the time we agreed to this despite all objections for the benefit the entire ecosystem gains via close cooperation between HLS releases and GHCup, but I am seriously questioning that decision right now if it only enables and validates such behaviour and leads to more threats of fracturing the ecosystem and total non cooperation with the release process of more projects, as can recently be seen on the cabal tracker: haskell/cabal#9437 (comment) It is not sustainable for a single person to produce GHC, HLS and cabal-install binaries across a slew of release branches, platforms and configurations without any cooperation from upstream maintainers and release managers. Unilateral demands are not a productive way forward, no matter how much the person making the demands has contributed in a personal and technical sense to the ecosystem. |
wz1000
force-pushed
the
wip/hls-2.5.0.0
branch
from
1098680
to
ebe8913
Compare
|
I have updated the patch to only change ghcup vanilla |
hls-metadata-0.0.1.json
Outdated
| @@ -1431,5 +1431,79 @@ | |||
| "9.8.1" | |||
| ] | |||
| } | |||
| }, | |||
| "2.5.0.0": { | |||
There was a problem hiding this comment.
We have to drop hls-metadata, because it corresponds to the default release channel, not vanilla (it's used by the vscode-haskell extension).
There was a problem hiding this comment.
We switch the vscode extenstion to using the vanilla channel in haskell/vscode-haskell#999
|
@hasufell Can you please propose a solution where users of HLS can immediately use a release AND the vscode-extension is using the default channel? It is not acceptable to HLS developers that the release is blocked from being distributed to user's due to a GHCUp policy about platform support which diverges from the HLS policy of platform support. The GHCUp policy of platform support is entirely up to GHCUp developers to provide, but if this policy affects the prompt distribution of releases then alternative means will have to be investigated about how to distribute binaries to users. You indicated in your blog post and on IRC that if users (ie, the HLS extension) wanted to use upstream vanilla bindists then they should modify the path to the metadata, which is exactly what Zubin has done in the vscode extension. The HLS developers feel like this is an acceptable option as it means that users can immediately use the new release of HLS. |
This is false. FreeBSD has been shipped for the past releases just fine. The HLS release manager this time decided to drop the FreeBSD support without any discussion. The issues in the Cirrus CI release pipeline had not been communicated to me during the release. Instead @wz1000 chose to carry on with the release, open the ghcup-metdata PR and then say "oh btw, I regressed the CI and dropped FreeBSD". This is unacceptable.
You are free to use another distribution channel if you please so. I will continue to provide HLS bindists.
That PR is broken. I've commented there. Please don't make decisions on distribution issues you don't understand fully. I'm very disappointed about how well-typed has been handling this HLS release and at this point, I'm not sure if you:
Where was this discussed? I am a HLS contributor too. Wrt the actual issue at hand: I have already updated GHC FreeBSD bindists and have communicated it right here. All that the release manager would have to do is update the cirrus CI config and trigger another run. But instead, they chose to comment on what they think GHCup should do (that is not for you to decide) and then raised broken PRs to vscode-haskell extension, instead of doing their job of providing a good set of bindists that I can ship. |
|
It seems I've also been accused of not being collaborative, which is a bold misrepresentation of facts:
In the context of this PR... I'm not sure what more collaboration you want from me:
I told Zubin to update the cirrus config and build the bindist, which is easy: diff --git a/.cirrus.yml b/.cirrus.yml
index fefa2d8c..267746f2 100644
--- a/.cirrus.yml
+++ b/.cirrus.yml
@@ -21,12 +21,18 @@ build_task:
GITHUB_WORKSPACE: ${CIRRUS_WORKING_DIR}
CABAL_CACHE_NONFATAL: "yes"
matrix:
- - name: build-ghc-9.2.5
+ - name: build-ghc-9.2.8
env:
- GHC_VERSION: 9.2.5
- - name: build-ghc-9.2.7
+ GHC_VERSION: 9.2.8
+ - name: build-ghc-9.4.8
env:
- GHC_VERSION: 9.2.7
+ GHC_VERSION: 9.4.8
+ - name: build-ghc-9.6.3
+ env:
+ GHC_VERSION: 9.6.3
+ - name: build-ghc-9.8.1
+ env:
+ GHC_VERSION: 9.8.1
install_script: pkg install -y hs-cabal-install git bash misc/compat10x misc/compat11x misc/compat12x gmake patchelf tree gmp libiconv
script:
- tzsetup Etc/GMT
@@ -40,8 +46,10 @@ build_task:
bindist_task:
name: bindist
depends_on:
- - build-ghc-9.2.5
- - build-ghc-9.2.7
+ - build-ghc-9.2.8
+ - build-ghc-9.4.8
+ - build-ghc-9.6.3
+ - build-ghc-9.8.1
timeout_in: 120m
only_if: $CIRRUS_TAG != ''
env:
@@ -56,13 +64,21 @@ bindist_task:
- tzsetup Etc/GMT
- adjkerntz -a
- - curl -o binaries-9.2.5.tar.xz -L https://api.cirrus-ci.com/v1/artifact/build/${CIRRUS_BUILD_ID}/build-ghc-9.2.5/binaries/out.tar.xz
- - tar xvf binaries-9.2.5.tar.xz
- - rm -f binaries-9.2.5.tar.xz
+ - curl -o binaries-9.2.8.tar.xz -L https://api.cirrus-ci.com/v1/artifact/build/${CIRRUS_BUILD_ID}/build-ghc-9.2.8/binaries/out.tar.xz
+ - tar xvf binaries-9.2.8.tar.xz
+ - rm -f binaries-9.2.8.tar.xz
+
+ - curl -o binaries-9.4.8.tar.xz -L https://api.cirrus-ci.com/v1/artifact/build/${CIRRUS_BUILD_ID}/build-ghc-9.4.8/binaries/out.tar.xz
+ - tar xvf binaries-9.4.8.tar.xz
+ - rm -f binaries-9.4.8.tar.xz
+
+ - curl -o binaries-9.6.3.tar.xz -L https://api.cirrus-ci.com/v1/artifact/build/${CIRRUS_BUILD_ID}/build-ghc-9.6.3/binaries/out.tar.xz
+ - tar xvf binaries-9.6.3.tar.xz
+ - rm -f binaries-9.6.3.tar.xz
- - curl -o binaries-9.2.7.tar.xz -L https://api.cirrus-ci.com/v1/artifact/build/${CIRRUS_BUILD_ID}/build-ghc-9.2.7/binaries/out.tar.xz
- - tar xvf binaries-9.2.7.tar.xz
- - rm -f binaries-9.2.7.tar.xz
+ - curl -o binaries-9.8.1.tar.xz -L https://api.cirrus-ci.com/v1/artifact/build/${CIRRUS_BUILD_ID}/build-ghc-9.8.1/binaries/out.tar.xz
+ - tar xvf binaries-9.8.1.tar.xz
+ - rm -f binaries-9.8.1.tar.xz
- bash .github/scripts/bindist.sh
bindist_artifacts:The HLS release manager gets paid to do the release. I'm unpaid and severely sick and have to deal with these unpleasant encounters, which are one of the primary reasons for people burning out. But apparently my contributions are not enough and I will have to keep cleaning up after everyone, otherwise I'm labelled as "uncollaborative". And on top of that, I have to hear "please be faster with your releases, or else". Please re-consider how you're treating unpaid volunteers. |
|
It is not as simple as rerunning CI, Julian, the sole aarch64 darwin runner is low on space and only succeeded last time because the runner was completely reset. I opted to release without FreeBSD binaries for 9.2.5 and 9.2.7 because
|
We need only the FreeBSD portion of the CI, which is decoupled from the rest. There's no reason to re-run the github side.
Yes, those things need to be raised by the release manager in time and in advance and not at the very last step of the release.
But GHCup did not. To re-iterate: you have no obligation whatsoever to provide any binaries for GHCup. But if you don't, you can't complain that it took longer to adopt a release. Even if you do, there may be other reasons to delay a release or entirely skip a release. GHCup is not an installer.
I don't want to discuss distribution issues with every upstream developer team, every time, for every release or every single CI change. I just can't. So all the distribution decisions lie completely within the GHCup team. The vanilla portion of the ghcup-metadata is completely up to upstream (you). You can commit and push to those at will. You are also free to advertise those channels as the "bleeding edge" channel, but I expect you to inform your users that they may get borked bindists, since GHCup does zero quality control on those and they already contain a fair number of borked bindists. Making those default anywhere is out of the question. |
wz1000
force-pushed
the
wip/hls-2.5.0.0
branch
from
ebe8913
to
54bd184
Compare
|
I have updated the patch to not modify hls-metadata.json
I did try to rerun it, but CirrusCI refuses to do so. It is also confusing for users and debuggers if
I don't think it is acceptable to delay the HLS release for everybody if we are waiting for FreeBSD ghc bindists.
I agree in principle, but to block users (of both ghcup and the vscode extension) from accessing the release (which passed all the GHCup metadata CI checks) does not seem like it is in the best interest of users. If FreeBSD CI is fixed, those binaries can always be added later. If I had added FreeBSD binaries for 9.2.5 and 9.2.7 for this release, users on FreeBSD would have been precluded from more complete upstream binary support, since GHCup does not support metadata revisions. So I do not understand the objection to merging this patch in its original state. I have the following questions about policy for the default yamls going forward:
|
Please have this discussion with debian, Fedora, nixpkgs, brew, ArchLinux and Gentoo as well. So no, this is not how redistribution works. Instead users can:
url-source:
- GHCupURL
- ghcup-info:
ghcupDownloads:
HLS:
2.5.0.0:
viTags: []
viChangeLog: https://github.com/haskell/haskell-language-server/blob/master/ChangeLog.md
viSourceDL:
dlUri: https://downloads.haskell.org/~hls/haskell-language-server-2.5.0.0/haskell-language-server-2.5.0.0-src.tar.gz
dlSubdir: haskell-language-server-2.5.0.0
dlHash: 515bbff3eca30a5d584f9a0b1b64651f9bd0ea666888c70e31692a1c95528c36
viArch:
A_64:
Linux_Debian:
'< 10': &hls-2500-64-deb9
dlUri: https://downloads.haskell.org/~hls/haskell-language-server-2.5.0.0/haskell-language-server-2.5.0.0-x86_64-linux-deb9.tar.xz
dlSubdir: haskell-language-server-2.5.0.0
dlHash: ba336f29647492134509e83da0cc8c8ecfbe3d264bd2c6825a1f00344f602e53
'(>= 10 && < 11)': &hls-2500-64-deb10
dlUri: https://downloads.haskell.org/~hls/haskell-language-server-2.5.0.0/haskell-language-server-2.5.0.0-x86_64-linux-deb10.tar.xz
dlSubdir: haskell-language-server-2.5.0.0
dlHash: 9503db02a03e3d50d78b42b866fb32478dedb9906d278dd1ad4432740b3d3d36
unknown_versioning: &hls-2500-64-deb11
dlUri: https://downloads.haskell.org/~hls/haskell-language-server-2.5.0.0/haskell-language-server-2.5.0.0-x86_64-linux-deb11.tar.xz
dlSubdir: haskell-language-server-2.5.0.0
dlHash: fe8e97dd6de79b6df1b0138ee2090d392b85cbf7df13d1efa8a3827091cfef48
Linux_Ubuntu:
'( >= 16 && < 19 )': &hls-2500-64-ubuntu18
dlUri: https://downloads.haskell.org/~hls/haskell-language-server-2.5.0.0/haskell-language-server-2.5.0.0-x86_64-linux-ubuntu18.04.tar.xz
dlSubdir: haskell-language-server-2.5.0.0
dlHash: d43e4858ff798c147a7c12f5d92cf8ca1fa345e7da3f3c1f05acf7bd0f83ee26
'( >= 20 && < 22 )': &hls-2500-64-ubuntu20
dlUri: https://downloads.haskell.org/~hls/haskell-language-server-2.5.0.0/haskell-language-server-2.5.0.0-x86_64-linux-ubuntu20.04.tar.xz
dlSubdir: haskell-language-server-2.5.0.0
dlHash: 7c1800a7af1bf5777114aa7e96cca94fdf6b34dc839a7eb3ad725e28efac0250
unknown_versioning: &hls-2500-64-ubuntu22
dlUri: https://downloads.haskell.org/~hls/haskell-language-server-2.5.0.0/haskell-language-server-2.5.0.0-x86_64-linux-ubuntu22.04.tar.xz
dlSubdir: haskell-language-server-2.5.0.0
dlHash: 641888bc81570f8c66d7def5f05d64419b29d51e1d61b2470f4076555b54d5e7
Linux_Mint:
'< 20':
dlUri: https://downloads.haskell.org/~hls/haskell-language-server-2.5.0.0/haskell-language-server-2.5.0.0-x86_64-linux-mint19.3.tar.xz
dlSubdir: haskell-language-server-2.5.0.0
dlHash: 49944981fa4b6489aace7b7c1ab71a5c8b2f650c50cd6e5dad8fb107a11f042a
'(>= 20 && < 21)':
dlUri: https://downloads.haskell.org/~hls/haskell-language-server-2.5.0.0/haskell-language-server-2.5.0.0-x86_64-linux-mint20.2.tar.xz
dlSubdir: haskell-language-server-2.5.0.0
dlHash: 4ff9d1edf6b07f6339680580d73afb2f1004189da4751fe205d0e5d6f48f83bf
'>= 21': *hls-2500-64-ubuntu22
Linux_Fedora:
'< 33': &hls-2500-64-fedora27
dlUri: https://downloads.haskell.org/~hls/haskell-language-server-2.5.0.0/haskell-language-server-2.5.0.0-x86_64-linux-fedora27.tar.xz
dlSubdir: haskell-language-server-2.5.0.0
dlHash: a1d321c098949635d5e83d85a14d472ce874884096843fbfccc74cbda9d6a162
'>= 33': &hls-2500-64-fedora33
dlUri: https://downloads.haskell.org/~hls/haskell-language-server-2.5.0.0/haskell-language-server-2.5.0.0-x86_64-linux-fedora33.tar.xz
dlSubdir: haskell-language-server-2.5.0.0
dlHash: f2c233ee6f788cbf337c55fcaf0902fd1e363f581979437735c90483f97c5cd7
unknown_versioning: *hls-2500-64-fedora27
Linux_CentOS:
'( >= 7 && < 8 )': &hls-2500-64-centos
dlUri: https://downloads.haskell.org/~hls/haskell-language-server-2.5.0.0/haskell-language-server-2.5.0.0-x86_64-linux-centos7.tar.xz
dlSubdir: haskell-language-server-2.5.0.0
dlHash: 34f643436b3e2e2a68a1d89ff1db7c3c0bde25af27de981b513aa8cdbfb5ca9e
unknown_versioning: *hls-2500-64-centos
Linux_RedHat:
unknown_versioning: *hls-2500-64-centos
Linux_UnknownLinux:
unknown_versioning:
dlUri: https://downloads.haskell.org/~hls/haskell-language-server-2.5.0.0/haskell-language-server-2.5.0.0-x86_64-linux-unknown.tar.xz
dlSubdir: haskell-language-server-2.5.0.0
dlHash: 79bdb285910a6940ddb7961ea0ffad1e5f9101afdcc332355dc5c67b821775c9
Darwin:
unknown_versioning:
dlUri: https://downloads.haskell.org/~hls/haskell-language-server-2.5.0.0/haskell-language-server-2.5.0.0-x86_64-apple-darwin.tar.xz
dlSubdir: haskell-language-server-2.5.0.0
dlHash: 189e7dadad22d330052f5257c9724f834e1373ea3213f0b12a4a1b8a9c45a62e
Windows:
unknown_versioning:
dlUri: https://downloads.haskell.org/~hls/haskell-language-server-2.5.0.0/haskell-language-server-2.5.0.0-x86_64-mingw64.zip
dlHash: 15a2536e30ee0f5cd226a3f37f907f1a1121ce9ff451d1b7b738138fdb17d699
A_ARM64:
Linux_UnknownLinux:
unknown_versioning:
dlUri: https://downloads.haskell.org/~hls/haskell-language-server-2.5.0.0/haskell-language-server-2.5.0.0-aarch64-linux-ubuntu20.tar.xz
dlSubdir: haskell-language-server-2.5.0.0
dlHash: 47b5daf644cbfafc097470cdde7add6060f9fd27e0d4b746ccd11f8d23524c16
Darwin:
unknown_versioning:
dlUri: https://downloads.haskell.org/~hls/haskell-language-server-2.5.0.0/haskell-language-server-2.5.0.0-aarch64-apple-darwin.tar.xz
dlSubdir: haskell-language-server-2.5.0.0
dlHash: 2e5083ebf7fc9dd3c5aa31059f9336bec4407fffb21b93a20decb49e9cf880a4Amazing. You can inform your users of these possibilities.
Yes, please change that policy to "announce release after ghcup-vanilla-x.y.z.yaml has been updated". The one-shot mechanism
This is up to GHCup's discretion, resources and judgement call. Before all this bikeshedding started, I had a burst of energy and wanted to fix FreeBSD. I now regret doing that. |
I think it would be good for both upstream developers and users to make this explicit. Concretely, what happens if and when you are not around? |
This is why the HF is in the process of hiring Obsidian to aid GHCup development. I have not decided what to do if I am permanently gone. It is possible that ownership will fall into HF hands or some specific individual. This has not been decided yet. At any rate, ghcup is easy to fork, should this project really fall into chaos. You can also fork the ghcup-metadata repo and maintain a different There's also some design space that can be explored wrt combining yaml metadatas, e.g. via some algebra? Say, as a user you want to say "always use the default channel, except for HLS versions higher than 3 use another channel". But I'm not sure whether that's overkill. Distributions like Gentoo do not provide this (last I checked): a repository (equivalent of GHCup metadata file) is a self-contained unit. |
|
I think the channels are currently quite hard to maintain (i.e any typo or bug has to be fixed in multiple files). It is also hard to tell the difference between the channels. It would be nicer if there were bindist variants as part of a combined description, instead of completely orthogonal channels, especially when most of the contents are the same. This could be extended further than just "default" and "vanilla", for example "profiling", "debug symbols", "integer-simple" etc. |
No one has provided a good templating approach yet.
I think I've sufficiently documented them here, I hope: https://github.com/haskell/ghcup-metadata#metadata-variants-distribution-channels
Sure, "profiling", "debug" and "integer-simple" channels make sense. I don't see any conflict with the existing ones. The main issue is that some channels are "main channels" (e.g. define |
No, I mean comparing the files themselves to see what exactly is different. |
That's a job for a semantic yaml diff tool. https://www.yamldiff.com/ seems to be not so bad. For cli I gave dyff a quick try and it seemed ok: https://github.com/homeport/dyff |
CirrusCI refuses to build FreeBSD binaries after restarting.
Since there are no FreeBSD ghc bindists for any of the latest minor
versions of the GHCs HLS supports, drop them.