feature: per-machine lockfiles OR conditional lockfile entries

[bruxisma]

Did you check the docs?

• [x] I have read all the lazy.nvim docs

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

The use of a lockfile so I can keep my plugins synced across multiple machines has been a huge time saver most of the time for me. However, I have some issues that result when I have "per machine" plugins. To explain this, I will show a snippet from my neovim config

plugins.lua

# inside of `plugins.lua`
local machine = load("machine")

local plugins = {
  -- common plugins listed here
}

return vim.list_extend(plugins, machine)

init.lua

require("lazy").setup("plugins")

I do this because there are some plugins I sometimes have to use for work or for some platforms where the plugins don't work for other operating systems. I do this with most configurations that support multiple files. e.g., git, and my daily shell driver.

Typically this "machine" module/config/shell script is added as an empty file to my git repository and then removed from the update-index within git.

An issue I discovered recently is that plugins are always put into the lazy-lock.json file and, upon restore on a platform where they are not defined, are immediately removed from the system, and the lazy-lock.json file is updated and the machine specific plugin is removed, causing more diffs to occur in the lockfile that are necessary.

Describe the solution you'd like

I would like there to be something that lets me point to more than one lockfile or specify a dependency should go into a separate lockfile. Alternatively, some way to specify that a dependency is "machine specific" and shouldn't be removed from the lockfile even if the plugin does not exist locally on the machine.

One option I could see is that for setup() we can specify multiple modules and each one mentioned receives its own lockfile:

require("lazy").setup("plugins", "machine", "a-secret-third-module")

However, I'm unsure how well this would work in practice.

Describe alternatives you've considered

I briefly tried a small post-fetch script that would try to merge manually generated JSON files, but this ended up causing a TON of problems in practice, including clobbering of entries, or outright merge conflicts. There aren't many paths available if I'm just storing the raw configuration data in my dotfiles.

Additional context

No response

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[bruxisma]

😔