Initial packspec support

[folke]

Initial support for pkg.json and lazy.lua files part of a plugin repo.

Goals:

• support the pkg.json with a lazy extension in lazy
  • lazy can contain any valid lazy spec fields. They will be added to the plugin's spec.
• support a lazy.lua for more advanced use-cases. This file should return a lazy spec
  • Only use this if the custom.lazy field is not sufficient for your use-case.
  • this functionality is currently disabled since it's not really needed

There are two types of dependencies in lazy:

• runtime dep meaning that the dep should be loaded when the plugin loads
• env dep meaning that the dep should be installed in the user's environment
• lazy transforms the packspec dependencies to the second type to allow more flexibility for the plugin developer
• when version is "*" or "", the dependency is for the latest HEAD. * explicitly selects the latest stable version.
• version supports the npm semver range syntax, except for the combined ranges

On install or update, lazy combines all package.lua in a single cached file for better performance.

Commands

• :Lazy pkg: reloads all pkg.json files. This is useful when developing a packspec for a plugin
• :Lazy pkg plugin_name(s): additionally shows the resolved lazy spec based on the plugin's packspec

[justinmk]

support the pkg.json with a lazy extension in custom.laz

Probably can switch to just lazy (don't need custom) since pkg.json likely won't disallow undefined/unknown fields (like package.json).

[folke]

@justinmk updated!
I've also disabled support for a repo's lazy.lua file. The json format should cover 99% of the use cases already.

[justinmk]

• env dep meaning that the dep should be installed in the user's environment

what does this mean concretely? installing in system $PATH, or...? (I can't find "env dep" in lazy's readme or code)

[folke]

@justinmk you won't find that in the code, since I just made up those terms, which are admittedly not that great.

It's more related to Neovim's opt packages.

With env dependency, I just mean that a plugin needs another plugin to be an opt or start plugin.

A runtime dep, is where a plugin needs another plugin to be an opt or start plugin and additionally needs to have that other plugin loaded (packadd) when it loads.

With lazy, lua dependencies are resolved automatically, meaning that if a plugin depends on a module of a plugin that has not been loaded yet, then that other plugin will be automatically loaded.

The dependencies in the packspec are currently converted to those env dependencies.

If a plugin also needs the plugin to be loaded when it loads, and in a way that is not covered by the auto-loading, they can specify that with lazy's existing spec syntax in the custom lazy field for the pkg.json file

[folke]

Closing in favor of #1530