Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What problem does this solve? #42

Open
justinmk opened this issue Jul 3, 2023 · 2 comments
Open

What problem does this solve? #42

justinmk opened this issue Jul 3, 2023 · 2 comments

Comments

@justinmk
Copy link
Member

justinmk commented Jul 3, 2023

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
Copy link
Member

clason commented Jul 3, 2023

  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
Copy link
Member Author

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").

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants