More strict behavior of `vim.pack.add()`

[echasnovski]

There are several areas where behavior of vim.pack.add() can be improved:

1. Make it enforce plugin state on disk to be the one specified in plugin spec. I.e. enforce spec.src and spec.version. This allows a more straightforward switching to different branch/tag/version: edit 'init.lua' and :restart. Currently it requires extra step of vim.pack.update() (which needs internet connection) to "sync" plugin on disk with to have proper version.

   To not affect startup performance, this requires having a persistent on-disk storage of the plugin state (to be able to even detect the value change).

   The cost of this "enforce state" approach is that users can not see beforehand and confirm/deny which changes will be applied. They would still be present in the log file for inspection, though. Relevant discussion is here.

2. Decide how to treat several vim.pack.add() calls for the same plugin in the same session. Should it always force the state on disk or should it error for any second+ call for the same plugin (forcing to go "edit init.lua and restart" route)?

[justinmk]

edit 'init.lua' and :restart. Currently it requires extra step of vim.pack.update()

I wouldn't index much on this. Before we release Nvim 0.12, :restart will support arbitrary "startup script", so you can do :restart lua vim.pack.update() to run update() after restart. #34822

Does that change the urgency of this use-case?

this requires having a persistent on-disk storage of the plugin state

Is there a risk of conflicts with other running Nvim instances?

2. Decide how to treat several vim.pack.add() calls for the same plugin in the same session. Should it always force the state on disk or should it error for any second+ call

error

[echasnovski]

I wouldn't index much on this. Before we release Nvim 0.12, :restart will support arbitrary "startup script", so you can do :restart lua vim.pack.update() to run update() after restart.

Does that change the urgency of this use-case?

It might, but the main problem here is that vim.pack.update() currently requires Internet access (as it's primary goal is to fetch and apply updates from source). So if the user decides to switch branch/tag/version, there should be Internet access. Which is not a huge deal in modern age, but not clean.

The original PR had vim.pack.update() include opts.offline for this kind of cases, but it was decided to wait with it. At least until there is more clarity with maybe vim.pack.add() being responsible for it (after there is lockfile support).

this requires having a persistent on-disk storage of the plugin state

Is there a risk of conflicts with other running Nvim instances?

There might be, yes. The same as with shada, swap files, and other similar mechanisms.

2. Decide how to treat several vim.pack.add() calls for the same plugin in the same session. Should it always force the state on disk or should it error for any second+ call

error

This is the easiest solution, yes. It might not be that simple, though (as I've remembered now). The main use case for allowing several vim.pack.add() calls for the same plugin (name) in the same session is to allow a more modular configs with dependencies. Something like this:

-- File '~/.config/nvim/plugin/telescope.lua'
vim.pack.add({
  'https://github.com/nvim-lua/plenary.nvim',
  'https://github.com/nvim-telescope/telescope.nvim',
})

-- File '~/.config/nvim/plugin/avante.lua'
vim.pack.add({
  'https://github.com/nvim-lua/plenary.nvim',
  'https://github.com/yetone/avante.nvim',
})

Each file here is made self-contained by including all dependencies. Additionally, in theory, there might be different version constraints for the same dependency: if they point to different branch/tag - error, if version ranges - use intersection.

Now the behavior is that second+ call for the active plugin (i.e. which was previously vim.pack.add()ed) is just silently ignored. I.e. "first call wins" and no checks for version / src compatibility is done across different vim.pack.add() calls.

[justinmk]

Is there a risk of conflicts with other running Nvim instances?

There might be, yes. The same as with shada, swap files,

Should we use shada to store this vim.pack state? (shada has its own "conflict" issues, but we probably want to solve that once for shada rather than for many different state-persistence mechanisms)

[echasnovski]

Should we use shada to store this vim.pack state? (shada has its own "conflict" issues, but we probably want to solve that once for shada rather than for many different state-persistence mechanisms)

It might be doable, but I think will add avoidable friction at least initially. My thought is that it might be reasonable to store this kind of information (src and version) in the "public" lockfile together with explicit hash state, but not yet sure. I plan to discuss in #34776 the structure of how to store "public" and "private" persistent data, but can't express my thoughts concisely yet.