Open
Description
What problem does a "packspec" solve?
The problem needs to be worth solving. #41 proposes to limit the scope to:
- Defining a dependency tree, in a distributed/federated mannger (no central package registry), using only URLs and versions.
- Enables plugin managers to install plugin dependencies without explicit instruction by the end-user.
- Enables package "aggregators" (example) to partially discover plugins by walking the dependency tree, which reduces maintenance and increases quality of the list.
- (TBD) Defining ecosystem-defined hooks for pre-install, post-install etc.
Anything else? Is this problem worth solving? Does #41 solve it?
Elevator pitch
packspec (or whatever "wild west half-baked dependencies declaration format") is merely a high-leverage, ultra-low-effort way to start formally connecting the existing web of vim/nvim dependencies. It doesn't preclude a LuaRocks or other centralized solution later, it simply formalizes what already exists.
Metadata
Assignees
Labels
No labels