2020-11 monthly release

[alanz]

Is there any reason we should not start preparing to tag a new release?

[wz1000]

It would be good to have #530 in

[jneira]

Maybe we should release a new version of hls-plugin-api but it needs a ghcide release

[alanz]

So, things are getting more complicated. What has changed in the hls-plugin-api?

[jneira]

@alanz not a big thing, it now exposes client settings as a shake action (it is used by hlint plugin)

diff --git a/hls-plugin-api/src/Ide/Plugin.hs b/hls-plugin-api/src/Ide/Plugin.hs
index 1ef7c3e..e509196 100644
--- a/hls-plugin-api/src/Ide/Plugin.hs
+++ b/hls-plugin-api/src/Ide/Plugin.hs
@@ -12,10 +12,13 @@ module Ide.Plugin
       asGhcIdePlugin
     , pluginDescToIdePlugins
     , mkLspCommand
+    , mkLspCmdId
     , allLspCmdIds
     , allLspCmdIds'
     , getPid
     , responseError
+    , getClientConfig
+    , getClientConfigAction
     ) where

 import           Control.Exception(SomeException, catch)
@@ -24,6 +27,7 @@ import           Control.Monad
 import qualified Data.Aeson as J
 import qualified Data.Default
 import           Data.Either
+import           Data.Hashable (unhashed)
 import qualified Data.List                     as List
 import qualified Data.Map  as Map
 import           Data.Maybe
@@ -31,6 +35,7 @@ import qualified Data.Text                     as T
 import           Development.IDE   hiding (pluginRules)
 import           Development.IDE.LSP.Server
 import           GHC.Generics
+import           Ide.Logger
 import           Ide.Plugin.Config
 import           Ide.Plugin.Formatter
 import           Ide.Types
@@ -587,4 +592,13 @@ getPrefixAtPos lf uri pos = do
 getClientConfig :: LSP.LspFuncs Config -> IO Config
 getClientConfig lf = fromMaybe Data.Default.def <$> LSP.config lf

+-- | Returns the client configurarion stored in the IdeState.
+-- You can use this function to access it from shake Rules
+getClientConfigAction :: Action Config
+getClientConfigAction = do
+  mbVal <- unhashed <$> useNoFile_ GetClientSettings
+  logm $ "getClientConfigAction:clientSettings:" ++ show mbVal
+  case J.fromJSON <$> mbVal of
+    Just (J.Success c) -> return c
+    _ -> return Data.Default.def

Imo it is not needed to release haskell-language-server and it should not block the monthly release

[alanz]

So what happens with the hlint plugin then? It's one of the big deals in the current version.

[jneira]

hlint uses the git submodule version so it will work. The released version is supposed to be used by external plugins and i am not aware of nobody doing it (there is 79 downloads in hackage though). Otoh the change is mainly an addition, no api breaking changes so it is not a big deal

[alanz]

So, are we doing this? Is everything merged that we want?

[jneira]

I hope this night will be able to merge the last ghcide bump

[pepeiborra]

I'm happy to upload a new ghcide release to Hackage if that helps?

[expipiplus1]

Is the release process written down anywhere? (Also, is bumping the version in nixpkgs part of it)

[pepeiborra]

ghcide 0.5.0 is up in Hackage

[srid]

is bumping the version in nixpkgs part of it

CC'ing @maralorn who I've seen do it, though not sure if as part of any predefined workflow.

[jneira]

@expipiplus1 afaik it is not and that would be good. Binaries release is automated with a github action simply creating the release in github (and i add some for windows, hard to make work in ci). Included the needed by ghcup. I think there is a script to generate the changelog, but not sure where it lives (or was it in hie?).

Yeah it is in hie so it should be copied here.

[maralorn]

@expipiplus1 The workflow is me watching the freenode channel for new releases. And once it's there, I bump the package in nixpkgs.

[expipiplus1]

Great! Looking forward to it!

On Sun, Nov 8, 2020, 7:13 AM maralorn notifications@github.com wrote:

@expipiplus1 https://github.com/expipiplus1 The workflow is me watching the freenode channel for new releases. And once it's there, I bump the package in nixpkgs.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/haskell/haskell-language-server/issues/567#issuecomment-723506912, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGRJXHBJ4TTAYZG6L2FMD3SOXH7ZANCNFSM4TJDHEGA .

[jneira]

The release of hls-plugin-api is in its own way: #575 (although it was not strictly needed for this)

[jneira]

As we are going to use a ghcide released version we can consider upload hls to hackage/stackage this time, as we will switch to an unreleased version in the future. The problem is users likely can aks for next hackage releases and we will have to sync ghcode/hls releases forever and ever.

[lukel97]

@expipiplus1 the release process is documented in docs/releases.md @jneira there's a newer version of that script in HLS GenChangelogs.md

[jneira]

@bubba great! as a penitence for forget you wrote it i'll try to do the release myself, following your helpful instructions :smile:

• release instruciotns here: https://github.com/haskell/haskell-language-server/blob/master/docs/releases.md
• changelog gen script: https://github.com/haskell/haskell-language-server/blob/master/GenChangelogs.hs

[maralorn]

@jneira Seeing, that ghcide and hls have very closely connected dev teams now, do you think it would be an issue to always release hls shortly before ghcide?

[jneira]

@maralorn yeah, it should be easier now (and in the foreseeable future) sync both packages, but ghcide still has its own users, lsp server and daml as downstream package so there could be still some frictions when releasing them.

That said this could be a good opportunity to setup the process to release hls to hackage. We could try it after the normal release.

However, as @fendor noted in irc, there still be the problem with mismatches between the ghc project and the used to compile hls, as the cabal/stack default install will not use automatically the convention we are exploiting in hls-wrapper (hls-${ghcVersion}). Maybe it could be solved (or workarounded) using existing build tool mechanisms.

Relevant issue in the cabal issue tracker: https://github.com/haskell/cabal/issues/6952

[maralorn]

Hm, I can‘t speak for other hackage users, but we in nixpkgs rely very much on getting our packages from hackage, so having hls there would save us a lot of work. (i.e. hls would auto update in nixpkgs)

When I think about other users I feel like the simplest case would be, that a user only has one ghc installed and does everything with that. That use case should work when simply installing hls from hackage, right?

Maybe put a note on hackage, that installing hls from hackage is only for advanced users?

[jneira]

Maybe put a note on hackage, that installing hls from hackage is only for advanced users?

And describe carefully the steps needed to get and use the correct version. The basic use case of an unique or main ghc on PATH and cabal is covered, but afaik it is not the case for stack (nor for advanced cabal users).

A workaround to use a locally installed copy of hls with the same ghc than the project is described here: https://github.com/haskell/haskell-language-server#test-your-hacked-hls-in-your-editor

Basically adds haskell-language-server as a dependency or in build-tool-depends, build the executable locally under dist-newtyle or .stack-work and make the extension/editor use that copy putting in the hls executable path setting the result of either cabal exec which haskell-language-server or $(stack path --dist-dir)/build/haskell-language-server/haskell-language-server. Ugh :worried:

Or we could add a new executable haskell-language-server-local-wrapper that will delegate the execution in the locally installed hls. :thinking:

[jneira]

After two retries due to gihub actions problems, the prerelease is completed. Only left upload windows binaries we are building locally and we could make it public.

[jneira]

Version 0.6.0 already released