neovim/packspec

What problem does this solve?

justinmk opened this issue · 2 comments

justinmk commented

What problem does a "packspec" solve?

The problem needs to be worth solving. #41 proposes to limit the scope to:

  1. 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.
  2. (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.

clason commented
  1. Explicitly stating "engine" compatibility (Vim 8.2+, Neovim 0.9+) as a stronger contract than a too-easily-overlooked line in a README (and possibly as a replacement for a bunch of homegrown has('foo') and executable('bar') boilerplate).
justinmk commented

Via https://twitter.com/oilsforunix/status/1680957458431213569 :

I have been lightly working on almost exactly this, many notes on https://oilshell.zulipchat.com (please join). Working name is "Silo" for dumb artifacts; "medo"/meadow for git-versioned trees. It's a "meta" package manager because it invokes containerized apt, pip, etc.

... No format yet, right now it's shell scripts making the on-disk format, dealing with root/non-root issues. It's focused on data too big for git as well.

... say you want to build something like a VSCode remote server image for neovim, and add say a whole Pandas stack - more coarse-grained composition. It can invoke any packager manager including a neovim one, but also pip etc.

This oilshell effort sounds more like a "package manager-manager" (like how cmake is a "build script generator").