mason.nvim

mason.nvim copied to clipboard

Is your feature request related to a problem? Please describe.

Many plugins in the ecosystem require external packages that aren't specific to editing. It is a pain to manage them through custom lua configs and even more of a pain to manage manually.

Describe the solution you'd like

mason.nvim is already a backend for installing external packages, why not allow it to support any type of tool (rather than just LSPs, DAPs, Linters, and Formatters)?

Perhaps it'd also make sense to support custom registries (for private tooling as well) or custom mason packages that could be used locally. Mason has a nice interface for defining the install method for a tool, it would be nice if we could use them without always having to send a PR. Maybe I should make another issue for this?

Additional context

A simple example is telescope.nvim. It requires (albeit optionally) ripgrep and fd.

Hello!

Many plugins in the ecosystem require external packages that aren't specific to editing.

Do you have any examples (other than telescope)?

mason.nvim is already a backend for installing external packages, why not allow it to support any type of tool (rather than just LSPs, DAPs, Linters, and Formatters)?

Mason is still very new. There's some fundamental limitations and shortcomings that make me vary of expanding scope. My standpoint so far is that if there's a very clear connection to Neovim, I'm not opposed to adding it (lemmy-help is a perfect example of this).

I primarily view Mason as a Neovim-native frontend for package management. I have no intentions whatsoever to make it a general purpose package manager, existing ones do the job much better in every aspect. Mason is a complement to these.

Perhaps it'd also make sense to support custom registries (for private tooling as well) or custom mason packages that could be used locally. Mason has a nice interface for defining the install method for a tool, it would be nice if we could use them without always having to send a PR. Maybe I should make another issue for this?

Reasons I don't have official support for custom packages/registries is because (i) I want to centralize packages for auditing, governance, and quality reasons - with nvim-lsp-installer in the past I saw a lot of people going the "easy" route of adding a custom server when my preferred option would've been that they contribute it to nvim-lsp-installer instead, and (ii) the public API is tailored for end-user interactions only (the internal installer APIs are not considered public and are subject to breaking changes whenever deemed necessary). With that said, I'm sure it'll happen with time, just need things to settle first. Also, you can quite easily add custom packages today by reaching into internals if you reeeaally want to have custom packages.

I see your point and I agree, mason shouldn’t expand towards a more generalized package manager. There are others and they do the job just fine.

It would probably make more sense if mason handled installing plugins (which I see you’ve mentioned on a Reddit thread). Any sub-dependencies or other oddities mason would be able to handle.

There are just a few large issues that would need to be addressed in order for it to work. 1.) It’s not scalable to manually PR plugins. It’s arguably a lot of work if all you want is for it to get up and running. 2.) You’d need some sort of versioning (which is a big issue in the plugin ecosystem). Although mason shouldn’t be the judge of versions, it should be the plugin maintainer. 3.) Going off of [2], plugins should probably maintain their own manifest file to declare things like version and dependencies. At this point though is mason even the right tool?

I don’t know, I’m just giving some thought to an ideal plugin manager that the neovim community has been really lacking. I’m not sure if all this is out of scope for mason, but it’s some food for thought.

Off the top of my head, here are a few other examples of plugins with external dependencies: vim-markdown-composer - requires markdown-composer from crates (or build it locally), they should probably have some prebuilt binaries telescope - ripgrep. fd, fzf-native

I'm sure there are more,

Thanks, that's helpful! If there are any packages that you think are missing please do open an issue using the New package request template, or even better open a PR! Per the contributing guidelines, if none of the existing package categories are a good fit it's a sign that the package is currently out of scope for Mason. I'm not opposed to expanding scope, but when doing so I want it to be well motivated and under controlled circumstances. It will happen in due course.

I'll go ahead and close this particular issue as there's nothing actionable, I hope I were able to add some clarity in how I'm thinking