You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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).
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").
What problem does a "packspec" solve?
The problem needs to be worth solving. #41 proposes to limit the scope to:
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.
The text was updated successfully, but these errors were encountered: