Feature discussion: Lockfile support

[EdenEast]

I have created a crude lockfile in my config. I then tried to create a packer extension plugin that used packer's
extension features like set_handler, and custom installer/updater but ran into issues. You can read my findings here.
My conclusion was that it needed to be integrated into packer itself. Here is my proposal for what a lockfile feature
would look like. I would be interested in implementing this and submitting a pr for it. I would like to prototype something like this.
I would like to hear your thoughts on this @wbthomason. Also should this be made into an issue instead?

Issues with current snapshots:

• Setting snapshot config option calls snapshot rollup every time neovim start
  • This preforms a git fetch every for every plugin in the snapshot file ever time neovim is started
• Not integrated into packer commands like install and update
• Snapshot file not formatted for diffing changes and not sorted (not idempotent).
  • Having an PackerSnapshotDone autocmd would at least let us call jq to sort and pretty print.
    This would make snapshot's diff understandable and idempotent.

Lockfile feature design

Config

local config_defaults = {
  -- ...
  lockfile = {
    -- Apply lockfile on packer commands
    enable = false,
    -- Default lockfile filepath. Defaults to config location as it should be commited into dotfiles
    path = join_paths(stdpath("config"), "lockfile.lua"),
    -- Update lockfile after an upgrade call
    update_on_upgrade = true,
  },
}

The lockfile is an optional opt in feature for users that would want it. This keeps the default use case for packer and
would have no difference for current users. For those that would want it they can enable a lockfile to be applied to
packer's plugin management functions install and update.

The lockfile is a lua file. This makes loading the lockfile a simple require or dofile. (Currently I have the
default location in the root next to the users init.lua file. This could also be lua/lockfile.lua so that it could be
loaded with a require instead of a dofile). The lockfile entries are also sorted so that multiple calls are
idempotent.

Commands

A new command would be added called upgrade. This would temporally disable the lockfile and then execute an update.
Once the update is finished the lockfile will also be updated if update_on_upgrade is enabled.

The other new command that would be added is lockfile. This command will update the lockfile with the current state of
your local plugins. The internal lockfile table would also be re-loaded. This is useful is someone sets
update_on_upgrade to false and only wants to update the lockfile once they have tested the upgrade is stable. If it is
not then they can just call update and the lockfile will be reapplied.

Applying lockfile

The lockfile is applied if:

• The plugin name is found in lockfile table
• The plugin is a git type (not local)
• There is no tag key

The lockfile is also checked and applied to any plugin spec defined in requires key.

Updating lockfile

Since local plugin types are ignored by the lockfile, if an entry exists in the current lockfile that value is reused.

Example lockfile

-- Automatically generated by packer.nvim
return {
  ["LuaSnip"] = { commit = "45fc3d8" },
  ["alpha-nvim"] = { commit = "79187fd" },
  ["catppuccin"] = { commit = "ecfb68b" },
  ["cmp-buffer"] = { commit = "62fc67a" },
}

Required changes

Currently plugin_specs are assumed not to change. When plugin.setup() is called in the manage function the
installer_cmd and updater_cmd are created there with --depth flags if the plugin has a commit field or not.
The --depth flag would have to be moved into the plugin.installer and plugin.updater functions. Also there would
have to be a check if the lockfile is enabled or not. Also if it is currently disabled while calling upgrade.

Extras Ideas

Commit dates

With the lockfile applied to both the install and update commands we can take advantage of actually knowing the
commit we want. Along with the commit hash we can also save the commit's date. This would then allow the use of
--shallow-since instead of --depth 999999. This makes clones and updates of repositories leaner both on
network and diskspace. Getting the commit's date in unix time is simple:

git show -s --format="%ct" HEAD

---

Update

I have implemented the feature here.