Remove Gleam

[lpil]

Hello! First, thank you for this this software, and for supporting Gleam. I'm the creator of Gleam, and I'm here representing the Gleam core team and Gleam (Neo)vim team.

We have been having trouble with the Gleam language server not behaving as expectected in Neovim, namely the incorrect version of the compiler being used. This was confusing as we have established tooling and conventions for managing versions of Gleam, and they seemed to somehow not work within Neovim.

Today it was tracked down to Mason, where the gleam package would install a whole new version of the programming language and then override the intentionally installed version. This was made worse by distributions such as LazyVim which would automatically install the package for the programmer.

The package here is installing the whole Gleam distribution, not just the editor tooling. It's analogous to the Mason Python package installing a whole new version of Python, rather than just language server for Python.

We'd like to remove this package, as we think that Mason should be used for installing editor tooling, and is not the right tool for installing the whole programming language and toolchain, especially if it does not respect the version that the programmer has requested.

Thank you for you time,
Louis

[williamboman]

Hello! Thanks for the thorough explanation, I understand. Unfortunately removing a package is not supported in mason.nvim as the registry contents also acts as the local database - users who have gleam installed via Mason would not be able to manage it in any way (for example uninstalling). The gleam executable and underlying package artifacts would remain permanently installed, requiring manual removal.

Your assessment is correct, Mason does not (yet) manage entire toolchains. Dart is a similar example, which I've denied adding to the registry for the reasons you've stated. I'd like to add that I'm working on multi-version installations with workspace "profiles", at which point I'll look into potentially expanding the scope of packages to also manage bigger scope tooling such as runtimes/languages.

Is it possible there are still valid use cases of installing gleam via Mason, or is it fundamentally broken? If the issue is widespread (I've not received any reports since it was added in may) we could add a deprecation notice to the package like so:

deprecation:
  since: v0.33.0
  message: <some informative message>

It would also be a good idea to remove the mapping in the https://github.com/williamboman/mason-lspconfig.nvim plugin as it's used for detecting LSP candidates for a given filetype (it also provides a very primitive auto-installation mechanism). As for Neovim distributions automatically installing things - I'm not sure I can do anything with regards to blocking gleam from being installed, the best approach would be to submit issues with them individually.

[lpil]

Hello! Thank you for the detailed reply.

Is it possible there are still valid use cases of installing gleam via Mason, or is it fundamentally broken?

If a person wanted to be able to use the language server but did not want to be able to compile, test, or run the Gleam code then it would be useful. I think this is likely not going to be something people want.

If the issue is widespread (I've not received any reports since it was added in may)

The language is quite new so the ecosystem isn't very large, and I suspect I'm the first person to work out what is happening. Also the language server isn't very mature so any incorrect behaviour is likely being attributed to us rather than the Mason configuration.

It would also be a good idea to remove the mapping in the https://github.com/williamboman/mason-lspconfig.nvim plugin as it's used for detecting LSP candidates for a given filetype

That does sound good, perhaps in that case the Gleam package could remind in this repo in case someone does want to opt-in for it.

I'm unfamiliar with that project and not sure exactly what it does. If I remove references to Gleam from it the LSP will still work thanks to lspconfig, but the link to the Mason package will be gone, preventing it from being unintentionally installed. Is that right?

[williamboman]

I'm unfamiliar with that project and not sure exactly what it does. If I remove references to Gleam from it the LSP will still work thanks to lspconfig, but the link to the Mason package will be gone, preventing it from being unintentionally installed. Is that right?

^{Apologies for late response}
Yeah so the mason-lspconfig.nvim provides a mapping between Mason packages and the lspconfig server configuration. This is to support features like automatic detection of packages to install (opt-in and can be disabled for specific packages)¹, the ensure_installed setting, and semi-automatic setup of servers (i.e. if Gleam is installed via Mason it'll provide a hook to set up the server). If the mapping is removed all of these features will silently stop working, only the ensure_installed feature will start warning the user that they're providing an unknown server to install. This, plus providing a deprecation message in the package definition here, will probably be enough to offboard users from using Mason at all for Gleam if that's the goal.

Mason itself doesn't really automatically install things, most things are explicitly opt-in, so if the goal is to get rid of the implicit automatic installations the best approach would be to inform common Neovim distribution that actually triggers the installation (I could help with this). In this case we could keep the Gleam setup as-is in Mason for users who still want to use it.

^{1 - automatic detection is based on which servers the user sets up via lspconfig}

[lpil]

If the mapping is removed all of these features will silently stop working, only the ensure_installed feature will start warning the user that they're providing an unknown server to install. This, plus providing a deprecation message in the package definition here, will probably be enough to offboard users from using Mason at all for Gleam if that's the goal.

Mason itself doesn't really automatically install things, most things are explicitly opt-in, so if the goal is to get rid of the implicit automatic installations the best approach would be to inform common Neovim distribution that actually triggers the installation (I could help with this). In this case we could keep the Gleam setup as-is in Mason for users who still want to use it.

Sounds great to me!

Forgive me but I'm very new to and unfamiliar with modern neovim, would you be able to help me to this? Or should I ask for help elsewhere?

[lpil]

Hi @williamboman ! We've been getting repeated reports of Neovim seemingly not working with Gleam, and this Mason config is the problem. Is there something we can do please? It really is becoming an issue for us 🙏

[williamboman]

Hi @williamboman ! We've been getting repeated reports of Neovim seemingly not working with Gleam, and this Mason config is the problem. Is there something we can do please? It really is becoming an issue for us 🙏

I understand. I've added a deprecation message and removed the gleam binary link (i.e. it won't be added to user's PATH). Installation will still be possible but it will effectively do nothing. I've also removed the mapping here, which is often used as a source by other plugins for automatic installation. Hopefully it'll alleviate most of the issues for now. Users who already have Gleam installed through Mason prior to this change will however manually need to uninstall/update the package for these changes to apply.

[lpil]

Thank you so much @williamboman ! I really appreciate your help!

[kbario]

TLDR: I think gleam is silently ignored by mason-lspconfig now that it has been deprecated, which makes for hard debugging, and maybe we should document this gotcha. I'm using kickstart.nvim's setup which pumps all LSPs through mason-lspconfig. Not sure if Mason is the correct place to raise this or kickstart.

---

@williamboman I am setting up neovim using kickstart.nvim and ran into an issue where I define the servers and then it runs through mason-lspconfig as below.

local servers = {
  gleam = {},
}
---
require('mason-lspconfig').setup {
  handlers = {
    function(server_name)
      local server = servers[server_name] or {}
      server.capabilities = vim.tbl_deep_extend('force', {}, capabilities, server.capabilities or {})
      require('lspconfig')[server_name].setup(server)
    end,
  },
}

Now that Mason no longer handles the gleam LSP, I think it skips it in the lspconfig setup handler, so the gleam LSP never gets configured.

I confirmed this by looking at the configured servers list in :LspInfo; it is not on the list when I leave it to mason-lspconfig to configure it,

but it is when I set it up outside of mason-lspconfig

I doubt you would want to do anything within the Mason ecosystem to cater for this edge case, but it could be good to document this somewhere.

Do you think there is a good place to do this in Mason? Or should I raise this in kickstart?