bug: Lazy restore update plugin's hash

[cathaysia]

Did you check docs and existing issues?

• [X] I have read all the lazy.nvim docs
• [X] I have updated the plugin to the latest version before submitting this issue
• [X] I have searched the existing issues of lazy.nvim
• [X] 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. :disappointed:

[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.

[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.

[cathaysia]

If the lock file does not work as expected, then what is the purpose of the lock file? Is it just psychological comfort?

[folke]

The lockfile always corresponds with the state of your plugins. Plugins that get installed automatically during startup use the commit info from the lockfile. Existing plugins with a different hash, update the hash in the lockfile.

[powerman]

What's the use case(s) for lockfile then?

Is there any official/recommended way to ensure two installations are in sync and use same versions of all plugins?

[s1n7ax]

With that behavior looks like it only pull the correct version for not installed plugins. I agree with others that it defeats the entire purpose of the lock file.

[rynoV]

Agreed this was unintuitive behaviour

For me a temporary workaround was to delete the plugin dir in ~/.local/share/nvim/lazy and delete ~/.cache/nvim/luac, then reopen nvim

[Lazerbeak12345]

I don't have any hashes in my init.lua, but I do have several projects set to "master" or "HEAD," and I still get this behavior.

If I can't restore a nvim instance to a specific snapshot using the lockfile, then it isn't doing anything for me.

Lazy should always set the plugins to match the lockfile, and only modify the lockfile when told to update plugins. (not the other way around)