-
-
Notifications
You must be signed in to change notification settings - Fork 287
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove Gleam #3872
Remove Gleam #3872
Conversation
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 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 now 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
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 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 |
Hello! Thank you for the detailed reply.
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.
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.
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 |
Apologies for late response 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 |
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? |
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 🙏 |
Gleam should not be installed through Mason. See mason-org/mason-registry#3872.
Gleam should not be installed through Mason. See mason-org/mason-registry#3872.
I understand. I've added a deprecation message and removed the |
Thank you so much @williamboman ! I really appreciate your help! |
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 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? |
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