mason.nvim
mason.nvim copied to clipboard
make registry.get_package more efficient
I've searched open issues for similar requests
- [X] Yes
Is your feature request related to a problem? Please describe.
Try this
local pkg_name = "debugpy"
local registry = require "mason-registry"
local pkg = registry.get_package(pkg_name)
vim.pretty_print(pkg)
Update: try before and after triggering the UI, e.g. :MasonInstall
you'll see that the entire Lang table is accessible/assigned with __index
{
__event_handlers = {
---
},
__event_handlers_once = {},
name = "debugpy",
spec = {
categories = { "DAP" },
desc = "An implementation of the Debug Adapter Protocol for Python",
homepage = "https://github.com/microsoft/debugpy",
install = <function 5>,
languages = { "Python" },
name = "debugpy"
},
<metatable> = {
__index = {
Cat = {
Compiler = "Compiler",
DAP = "DAP",
Formatter = "Formatter",
LSP = "LSP",
Linter = "Linter",
Runtime = "Runtime"
},
Lang = {
[".NET"] = ".NET",
["1С:Enterprise"] = "1С:Enterprise",
---
}
Describe the solution you'd like
Probably move Pkg.Lang to Reg.Lang instead, since it's the registry that should keep track of all available/supported languages rather than mason-core.
Describe potential alternatives you've considered
lsp-installer didn't need this index 😄 oh, and it's not used or needed in any of CI scripts either, AFAICT!
Additional context
semi related to #86 (?)
Hey! Hm I'm not following how it relates to efficiency? It's assigned to the metaclass singleton table itself, not each individual package object. The reason it's on the Package metaclass is for convenience reasons, so that package definitions only need to import the Package "class" to be able to express a fully valid package spec (excluding code related to installation).
The Pkg.Lang table will only incrementally populate itself when package definitions are loaded, so the fact that it's showing a bunch of languages is probably a sign that something else is loading a bunch (all?) Mason packages. This is something you generally want to avoid if you're chasing performance improvements (to avoid a large amount of require calls and scripting time).
@williamboman, okay, I thought I was going crazy there for a minute, but it seems that the trigger is opening the UI. It's easy to reproduce with any config.
Ah haha yeah the UI will load all packages. That in itself will probably eventually become a performance problem worth solving, but for now I consider it entirely negligible as it ought to be a deliberate and non-automated action by the user to open it (and we're talking penalties in the order of milliseconds).