Add the ability to point to a local repository

[perrin4869]

I've searched open issues for similar requests

• Yes

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

I would like to track the registry repository as a git submodule in my dotfiles repo manually. This would give me the option to manage updates more precisely and generally having more control over the setup.

Describe the solution you'd like

I'd like to be able to set the registries to be something like

    registries = {
        "file:path/to/my/registry",
    },

In this case, obviously MasonUpdate etc would be meaningless

Describe potential alternatives you've considered

No response

Additional context

I'm using a Makefile for some years now to manage and update my dotfiles dependencies/nvim plugins, etc. One of the cool things about this approach is that you can automate and curate updates using dependabot and github actions, etc. The goal is to add a submodule pointing to the mason-registry, setup mason to pick up packages from there, and only perform updates/installs to packages if the registry has changed (i.e., mtime has changed)

[williamboman]

Hello! The core registry contains 300+ packages each located in their own file. To fully load the registry one would have to read and YAML parse each file individually. This would have a very noticeable performance impact, as mason.nvim currently needs to load registries synchronously (i.e. freezing the editor). The github:mason-org/mason-registry registry source uses a precompiled JSON file, available via GitHub release assets, containing all package specifications.

If you want to manage the registry version, you could pin the registry version directly like so:

require("mason").setup {
  registries = {
    "github:mason-org/mason-registry@2023-08-12-hairy-coin"
  }
}

You can then replace the version component by pulling the latest version from the GitHub API and substituting it, should be fairly easy with sed/awk.

[perrin4869]

Oh I see! Well, the shortcoming with the solution for pinning the registry version is, you cannot rely on dependabot to keep it up to date
I guess in order for this to be feasible, there would need to be a mechanism to allow reading individual package.yml from the mason-registry repo during runtime, instead of relying on the huge compiled file.
This would actually be really cool, because at that point you could rely on the package.yml's mtime attribute to have a Makefile be able to decide whether or not to update the package.
I guess this would fall under, would you be interested in supporting such functionality? I'm guessing the target audience is minuscule

[williamboman]

Not sure I'm following re: dependabot and keeping packages up to date. This is already done upstream through Renovate, and will result in a new registry version whenever a package version is updated.

I think allowing local registry sources could be interesting from a testing perspective, but it will have certain penalties if one wants to use it outside of testing.

[perrin4869]

Oh, dependabot is capable of sending PRs for git submodules, like here. I use it to keep my dotfiles up to date (vim plugins, and other dependencies).
So it would be cool to add the mason-registry repo to my dotfiles as a git submodule and let dependabot take care of updating it as needed

[williamboman]

Ah ok I thought you were referring to using dependabot to update the packages themselves. I need to provide a way for external contributors to locally test package contributions, and I've thought about using this approach for that, so I'll see if it's feasible.

[williamboman]

I've opened an implementation for this in #1457. Again this is primarily for testing purposes, if you intend to use this for normal usage you might run some functionality glitches. This is because in order for the packages contained in a local registry (i.e. file:) to be available, the registry has to be "installed" first. This happens when you open the :Mason window, or run the :MasonUpdate command. You can also do this via Lua:

require("mason").setup()
require("mason-registry").refresh(function () end) -- see :h mason-registry.refresh()

Using a file: also requires yq to be installed in PATH. yq is available in the core registry so you can either first install it via Mason (before changing registries settings), or elsewhere on your system.

While I do some more testing, would you mind giving it a spin as well and see if it behaves acceptably?

[perrin4869]

Neat! I'll give it a try this weekend, thanks!
would be nice to remove the need for yq, maybe get some yaml parser, or convert the packages to json?
out of curiosity, what does refresh do in the case of a file registry?

[williamboman]

I've not been able to find any reliable Lua parsers for YAML, and I certainly don't want to write one myself, hence the yq dependency. The registry.refresh() ensures the local registry is able to provide packages. Without it mason's Lua API will report 0 packages available. Again this type of registry source is primarily for testing purposes and not primarily meant for normal usage.

registry.refresh() ensures that packages are loaded into mason.nvim and are available via registry.get_package() etc. I've however advised 3rd party consumers to use registry.refresh() before interacting with the registry, so adding it to your own local config might be redundant. mason.nvim itself will still function perfectly without it, installed packages will be available in PATH etc. without registry.refresh(). You could leave the registry.refresh() part out and it will likely function fine (depends on what other plugins you use that interacts with Mason's Lua API).

[perrin4869]

hm... maybe should try https://github.com/exosite/lua-yaml, it seems to be just 1 lua file, could just copy it over.
my main workstation is a Slackware box, and there's no easy way to get yq installed, would need to put together a SlackBuild for it, and since it's a golang program, that's a real pain in the ass. SlackBuilds are meant to be primarily run offline and building a golang application offline is near impossible haha

Edit: if comment support is a problem, there is a PR adding support

[perrin4869]

I just tested the branch, and opened a PR in my dotfiles repo: perrin4869/dotfiles#2415

The CI is failing because it cannot fetch the branch, not sure why, but it works for me locally when I checkout the feat/local-registry-source branch without issues!
With this in, installing mason packages will be much easier for me, thank you so much!
The only wish that I have is to remove the dependency on yq 😅

Edit: ok, I got the CI to pass, feel free to check how this works in action :)

[WhoIsSethDaniel]

Whenever I try to use it I get the following:

Failed to install registry FileRegistrySource(path=/home/seth/src/mason-registry). "...ugins/opt/mason.nvim/lua/mason-registry/sources/file.lua:79: E5560: Vimscript function must not be called in a lua loop callback"

I hard-coded values for yq and registry_dir (both of which use vim.fn functions to get their values) in that Lua file and it seems to work fine once I worked around the above problem. I don't know why it doesn't complain about the use of vim.fn.executable when checking for yq.

[williamboman]

Hm, that's probably happening because the registry gets initialized outside of the main loop (should not happen as a result of anything mason.nvim does). Does #1471 (fix/scheduler) fix things?

[WhoIsSethDaniel]

fwiw, I only saw the error appear when I ran :Mason.
The branch seems to work fine.