Will 0.9.0 and future releases be uploaded to hackage?

[hamishmack]

In haskell.nix we maintain a custom-tools list that allows us to pretend something is in hackage when it is not, but with haskell-language-server 0.8.0 in hackage (and working great from there) we were hoping this would no longer be necessary input-output-hk/haskell.nix#1015.

[jneira]

Hi! after publishing hls and all its plugins to hackage the upload has become non trivial. We want continue doing monthly releases to offer final users a updated version of hls and the plan is automate the hackage upload as much as possible.
But in the meanwhile our idea is no sync by default both processes (see #671 (comment))
That said, hls-0.8.0 will not be the last release uploaded to hackage for sure 🙂

[michaelpj]

The value of having it on Hackage is a lot less if it's not consistently updated. In practice that means you can't use Hackage if you care about having the latest version. Which is a shame.

I appreciate that the process is complicated, though!

[jneira]

@michaelpj out of curiosity, are you using hackage to install hls by default? if that is the case, how do you handle the issue of installing the appropiate hls+ghc version for the project at hand?

[michaelpj]

The usual answer: Nix :) So we get a local build for a particular project that uses the same compiler.

Until now I've been just building from a source checkout, but it's easier to build a package from Hackage. So I nearly switched it... but now I'm glad I didn't if Hackage isn't going to get regular releases 🤷‍♂️

I guess I'm not sure what the point of putting it on Hackage is, if not for people to build/install it from there. And if that's the point then not having all the versions undermines it!

Maybe this just suggests we shouldn't publish to Hackage until the process sucks less!

[berberman]

FWIW adding HLS to Arch Linux official repository would require not only HLS itself is uploaded to hackage but also its dependencies are up-to-date. Neither requirement is satisfied now, so this work gets blocked :(

[pepeiborra]

I am also keen on having an up-to-date build of HLS in Hackage, it's the only way we can use HLS on the work codebase.

What are the blockers to upload 0.9.0 to Hackage @jneira ?

[jneira]

no real blockers but doing it, revise sub packages changes, bump up versions (following PvP if possible) and version bounds and upload them to hackage

EDIT: I forgot we need a hackage release of ghc-exactprint

[pepeiborra]

Is anything blocking the release of ghc-exactprint?

For the subpackages, esp. the plugins, it's going to be tricky to coordinate Hackage uploads. Do you plan to pursue central coordination or let individual maintainers upload to Hackage on their own schedule?

[michaelpj]

It seems to me, perhaps wrongly, that in practice all existing plugins of HLS should be released in perfect lockstep with it, and don't really have meaningful versioning apart from HLS. In other words, I think they'd be perfect candidates for being multiple public libraries of a single package, whenever that's finally usable.

But in the short term, could we simplify the process if we stuck with this?

• All plugins have the same version as HLS.
• Plugins depend on HLS == the same version.

That doesn't help us with tidying version bounds, that's always a chore.

[jneira]

I think the hard dependecy line is between hls-plugin-api/ghcide and the plugins, hls itself only depends closely on ghcide session-loader (correct me if i am wrong!). I guess changes included in the actual 0.9.0 release for hls-plugin-api/ghcide would suppose version bumps in almost all plugins (but i am only guessing). But it has not be the case for future releases with no breaking changes in hls-plugin-api/ghcide.

We can bump up blindly all packages at once and require that version everywhere with no further analysis of course. But then we have to upload all of them even if it is not necessary.

Finally re upload i think there is no one that has permission to upload all plugins to hackage so some kind of coordination (and inevitably some lag) between plugin maintainers in hackage should be done, even only to do the final upload. Something similar to the final work done in #1175

ghc-exactprint could be uploaded afaik (//cc @alanz)

[michaelpj]

Right, so "everything is released in lockstep" is obviously coarser than it has to be. If nothing else, maybe some plugins don't change at all from version to version. But maybe it simplifies the process enough that it's worth it for now?

Finally re upload i think there is no one that has permission to upload all plugins to hackage

That seems fixable, though? Having a couple of "HLS release managers" with those permissions seems like a good idea. I doubt plugin authors are going to be upset by the idea!

[pepeiborra]

HLS maintainers already have an awful lot of work on themselves with the PR reviews, the issue tracker, the binary releases and the Hackage uploads of core packages like HLS and ghcide. Is it wise to pile the plugins on top? I doubt it...

[jneira]

Well, let's get down to business 🙂 : #1287

[jneira]

well, hls 0.9 is out so I think we can close this one