bug: Lazy restore update plugin's hash

[cathaysia]

Did you check docs and existing issues?

• I have read all the lazy.nvim docs
• I have updated the plugin to the latest version before submitting this issue
• I have searched the existing issues of lazy.nvim
• I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

NVIM v0.10.1

Operating system/version

fedora 40

Describe the bug

after restore plugin, some plugins's hash was updated.

Steps To Reproduce

1. clone your nvim config
2. run Lazy restore
3. lock file changed and some plugins's hash was updated.

Expected Behavior

hash shouldn't update

Repro

No response

[powerman]

It's not restore() updates lockfile. Lockfile is updated by setup(), before we get a chance to call restore().

Here is how to reproduce this:

1. Have lazy and plugin A installed.
2. Have lockfile which declares commit hashes for lazy, plugin A and plugin B - and these hashes did not match current HEAD for both lazy and plugin A.
3. vim.o.loadplugins=true
4. Call require('lazy').setup(...) with spec= contains plugin A and plugin B.

The result will be:

1. Plugin B will be correctly installed using commit hash from a lockfile.
2. Lockfile will be updated with current HEAD hashes for all plugins, which means hashes for lazy and plugin A will change.

This behaviour of setup() breaks use case when we wanna install on CI all plugins using versions from lockfile:

1. Have a lockfile with commit hashes for all plugins including lazy itself.
2. Have no plugins installed (and no lazy too).
3. Bootstrap lazy (it will clone latest main branch).
4. vim.o.loadplugins=true
5. require('lazy').setup({spec={all plugins here}}). All these plugins (except the lazy itself) are missing, so setup() will both install them using correct commit hashes from lockfile and update lazy's hash in the lockfile to current HEAD (i.e. latest main).
6. Then we call restore() which will do nothing while we expect it to restore lazy version to the one from original lockfile (before it was modified by setup().

[powerman]

To fix this issue setup() should be modifed to avoid changing existing hashes in a lockfile.
It still should modify a lockfile to add hashes for new plugins it just installed, of course.

[powerman]

Actually setup() does this because of default option install = { missing = true }. But disabling it does not solve the issue - we anyway need to choose what to call first: restore() (which will restore existing plugins to commit hashes from lockfile but also it'll remove commit hashes for non-existing plugins from lockfile) or install() (which will install missing plugins using commit hashes from lockfile but then update lockfile and set commit hashes for existing plugins to their current HEAD).

Looks like right now we can't get both and apply commit hashes from lockfile to both existing and missing plugins. 😞

[github-actions]

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.

[powerman]

bump

[s1n7ax]

Yep. This was happening for a long time. I use same config in two computers and when I restore the new changes in the other, it always show changes in lock file though I'm only restoring

[iton0]

Yep. This was happening for a long time. I use same config in two computers and when I restore the new changes in the other, it always show changes in lock file though I'm only restoring

@s1n7ax i have a similar setup as well. I created a post-merge git hook that just runs nvim --headless "+Lazy! restore" "+Lazy! clean" +qa. This seems to have provided a temporary fix for me.