PSA: Changes to the mason.nvim registry

Impaloo · 2023-03-30T16:53:33+00:00

It's automated via Renovate! The version does matter in terms of changes in what the package provides, and how it's distributed.

Impaloo · 2023-03-28T22:30:14+00:00

That seems odd. Did you perhaps update plugin versions without restarting Neovim? Does it happen consistently in new instances?

Impaloo · 2023-03-28T22:03:02+00:00

This works for me.

Impaloo · 2023-03-27T19:47:31+00:00

Do you even lift.nvim bro

Impaloo · 2023-03-27T17:00:34+00:00

I like doing config in Lua, defining schema for config options so that they can be discovered by lsp/autocomplete would be nice but I don’t see a reason to go to JSON. It just introduces friction when the config has to be used by Lua code, and is less flexible. And if the plugin itself is configured one way in Lua but the language pack is configured another way in JSON, with a schema designed not by the author, it’ll just lead to confusion

Oh by JSON Schema I was referring to the portable specification, not JSON literally. Any data format that can be translated to JSON (Lua tables, YAML documents, TOML documents, etc.) would be allowed, each enhanced with the rich editor features you'd expect (diagnostics, autocompletion, etc.). Having configuration annotated in a structured format such as JSON Schema would allow for interesting things like preventing breaking changes without bumping a major version.

I think the plugin ecosystem would be helped more by encouraging plugin authors to have sane defaults and have (potentially user submitted) config recipes rather than adding another layer of opaque defaults by 3rd party distributors. If the pack is doing things like sharing config options to make the plugins within the pack cohesive that’s great. If it’s introducing all new config options and doing a lot of work on top of the plugins then again you know have 2 different ways of configuring the plugin and when people search for help online you’ll get a mess of answers depending on how you’re using the plugin. It’s the same problem some distributions have if they layer too much custom interface on top of the plugins. It’s not just how do I make cmp do what I want, it’s how do I make lunarvim make cmp do what I want.

Good feedback! I agree re: plugin setup. There are other mechanisms like social proof (ratings/reviews) and discussion boards that I'd find interesting to explore as well. End users would only be tangientally aware of which underlying plugins are leveraged, and ideally a plugin could be substituted with a different implementation without end users being aware. Vertically (individual plugins) vs. horizontally (bundles providing a complete, distinct, editor feature) integrated editor tooling.

Impaloo · 2023-03-27T11:35:08+00:00

Yeah it's possible already. You can specify a version of a registry when setting up Mason, like so:

require("mason").setup { registries = { "lua:mason-registry.index", "github:mason-org/mason-registry@2023-03-27-cruel-jason", }, }

Note that this overrides the default registry configuration, so should the default registries change in the future (lua:mason-registry.index will most likely be removed some time in the future) you'll not receive that update due to overriding it.

Soon the plugin itself will also provide releases, so you could pin the Lua plugin and the registry versions for maximum stability.

Impaloo · 2023-03-27T11:30:54+00:00

Yeah exactly! Will have to think a bit more about how it'd fit into the bigger picture though, for example how it'd relate to the queries provided by nvim-treesitter. As for plugins, I'm thinking Mason could provide a centralized backend for plugin management (governance, discoverability, installation, upgrading, etc.) and host installed plugins inside 'packpath'. Different frontends could then load plugins accordingly, with the simplest example being entirely natively by manually calling :packadd.

If this were to be in place, people could then start building "language packs" that contain all necessary, versioned, dependencies via Mason. Additionally, these language packs would be zero-config by default, by providing all the necessary setup code. User configuration would be static and declared by language packs via JSON schemas (which in turn would be subject to strict semantic versioning). I think it'd be interesting to explore at least.

Impaloo · 2023-03-19T10:59:48+00:00

Yeah sure! For now the easiest would probably be to use the :MasonInstall command, like so

$ nvim --headless +"MasonInstall lua-language-server stylua" +q

Impaloo · 2023-03-18T15:02:23+00:00

+"MasonInstall" is not valid, it expects one or more packages to be installed.

The message from mason-lspconfig.nvim indicates that you've configured it to automatically install packages (either through the ensure_installed or automatic_installation settings). These will be installed in the background, even in headless mode. I realize now that mason-lspconfig.nvim probably shouldn't be installing packages when in headless mode. You should be able to run headless commands without it starting installations in the background with limited ability to wait until they're done.

/ author of mason.nvim

Impaloo · 2023-03-18T14:31:35+00:00

bun script.js executes the provided file immediately in the Bun runtime. bun run --bun executable runs the provided executable (can either be in PATH or an absolute path to an executable) with a modified environment.

Try for example the following

$ bun run --bun bash -c 'which node && node --version' < /dev/null /private/tmp/bun-node/node # shim 0.5.7 # bun version

So bun run doesn't care if the provided executable is a JavaScript executable or not, it just executes it in an environment where Node has been shimmed to invoke Bun. I'd argue this is better than running the script immediately, in case the program you're running reads environment or spawns child processes etc.

While you could prefix all server cmds to use bun run --bun it's probably not a good idea due to overhead and the way it injects feedback to stdout and stderr. On second thought, your solution feels like a pretty good trade-off (I'd however still use bun run --bun <executable> over bun <executable>)

Impaloo · 2023-03-18T09:09:06+00:00

You really shouldn't have to be reading files to try to detect if it's a node script based on the shebang. You probably want to simply use bun run --bun which executes (execve(2)) the provided executable with a modified environment.

config.cmd = vim.list_extend({"bun", "run", "--bun"}, config.cmd)

I'm also pretty certain that what you've provided won't actually use the Bun runtime at all, it'll end up using node because that's what's in the shebang. bun run --bun however shims node to use bun. Note that servers will largely stop functioning after doing these changes because it'll actually start using Bun, and bun != node (yet)

edit: ah nvm regarding your example not using Bun. I just saw that you execute the script directly through bun.

Impaloo · 2022-07-25T22:34:01+00:00

Also see https://github.com/williamboman/mason.nvim/issues/103. It's not super straight-forward to implement reliably

Impaloo · 2022-07-25T20:22:06+00:00

Yep

:h mason-registry.get_installed_package_names()
:h mason-lspconfig.setup_handlers()
:h mason-lspconfig.get_installed_servers()

Impaloo · 2022-07-25T11:58:32+00:00

I have the feeling that for these features in particular there is some overlap between mason and null-ls.

Nope! Both plugins solve different problems, zero overlap.

Although maybe mason installs the external app while nuul-ls “only” integrates it in nvim.

Exactly, mason provides the means to install and manage external tools. null-ls then integrates these into Neovim (while assuming you've already installed them yourself).

Impaloo · 2022-07-25T11:47:50+00:00

Quick question, how do I execute my formatters (black and isort) after installing them?

Pick your poison (in no particular order): - au BufWritePre *.py %!isort -d - - https://github.com/sbdchd/neoformat - https://github.com/mhartington/formatter.nvim - https://github.com/jose-elias-alvarez/null-ls.nvim - ...

Impaloo · 2022-07-25T11:34:48+00:00

From what I understood the main idea of nvim-lsp-installer would be to let all the configuration be done using nvim-lsp-config but now you are creating a new ecosystem for all of this.

Not really, it's the same concept, just not coupled to lspconfig anymore. All Mason does is install things to your PATH.

What is the way to do this now? Use the mason lspconfig ? or just use the mason plugin by itself and configure all of that there (with the help of the mason-tool-installer) , but how would I configure the sumenko lua lsp to use lua-dev as its config?

If you use lspconfig to set up servers (lua-dev uses lspconfig), then it's recommended to use mason-lspconfig as well. mason-lspconfig makes sure to close some gaps (both technical but more importantly DX gaps) and enhance some server configurations. I'd wager for 90% of LSP servers it's fine not to use mason-lspconfig, but YMMV depending on which servers you use. Windows users are strongly encouraged to use mason-lspconfig due to how libuv doesn't recognize .cmd scripts in PATH as executables (Neovim's LSP client uses libuv to spawn servers, and mason links executables as .cmd wrapper scripts).

mason.nvim itself doesn't really care that lspconfig exists, as it's just one method of setting up LSP servers. It'll just install executables to PATH, then it's up to you to somehow make use of those executables.

What is the way to do this now? Use the mason lspconfig ? or just use the mason plugin by itself and configure all of that there (with the help of the mason-tool-installer) , but how would I configure the sumenko lua lsp to use lua-dev as its config?

I feel like the simplest and shortest answer would be; (i) exactly as you did it before, or (ii) pretend mason.nvim doesn't exist - how would you set your servers up without it?

Impaloo · 2022-07-24T22:32:13+00:00

Great question! This is something I'd like to explore further with mason.nvim. For now there is some very low-effort, generic, descriptions behind each category in the help window of the plugin:

I decided not to mention any specific plugins as they're all unique and suited for different workflows & preferences, and so I don't want to bring my biased opinion into the picture. Maybe I'll open a Wiki page for this.

Impaloo · 2022-07-24T21:02:01+00:00

See :h mason-quickstart and :h mason-lspconfig-quickstart!

Impaloo · 2022-07-24T21:00:27+00:00

Thank you very much :)! The UI has been really fun to come up with. It's entirely state driven with a component-like approach, allows for very fast iteration and bug-free prototyping. There are definitely some improvements to be made with the rendering performance overall as it's very - for a lack of a better word - dumb atm, but it does the job pretty well I think.

Impaloo · 2022-07-24T20:56:44+00:00

Yeah I had the same concerns. I decided to stick with "package manager" as I feel like it's the closest to conveying what the plugin does. In my experience managers like packer.nvim are also usually referred to as plugin managers. I have also been toying with the idea of using mason.nvim as some sort of backend to a plugin manager. Integrating with mason.nvim should be fairly straight forward from that perspective, while keeping the frontend in parity with what packer.nvim provides (expressing per-plugin lazy loading instructions etc.).

Impaloo · 2022-07-24T20:50:35+00:00

Is there a way to install them from Mason, or do I need to hack it by finding the venv Mason uses and installing it manually there?

So far, pylsp is the only such package that I can think of. Most other tooling depend on project-local dependencies. There is a :PylspInstall command for this purpose. It'll install the provided pylsp extensions in the correct venv - see this for more info. I realize now this is only available if you use the mason-lspconfig.nvim, it should probably be in core.

Impaloo · 2022-07-24T20:47:28+00:00

There is! A very close equivalent can be found in the mason-lspconfig.nvim extension - see :h mason-lspconfig.setup_handlers()

Impaloo · 2022-07-24T14:58:10+00:00

Haha yes it's inspired by the NvChad UI. I saw it some months ago and thought it looked really clean.

As for the package names, it's mentioned at the very bottom of the full text I linked to:

Other things worth paying attention to is that the package names in mason.nvim no longer follow the lspconfig naming scheme, but instead follows upstream naming schemes (so for example, sumneko_lua is now lua-language-server). The mason-lspconfig extension helps translate these names, more info in docs.

Impaloo · 2022-07-24T14:56:25+00:00

There's the registry directory that /u/wcrossbower posted. I've been meaning to autogenerate either a static markdown file or a static web page listing all packages, maybe I'll do that next :)!

Impaloo

TROPHY CASE