What problem does this solve?

[justinmk]

What problem does a "packspec" solve?

The problem needs to be worth solving. https://github.com/neovim/packspec/issues/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]

3. 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]

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

[sarmong]

Is this also intended to be used by plugin managers to generate users' config dependencies?

[justinmk]

It is intended to calculate dependencies. I don't understand your question.

[sarmong]

From all the discussions I see, the conversation is about transitive dependencies. If a user wants to install telescope.nvim, they wouldn't need to specify plenary.nvim, because telescope would have a pkg.json in their repo which would specify that it needs plenary and package manager would see it and install the dependencies needed. Is my understanding correct?

My question is about whether it should play a role of lazy-lock.json, deps-snap.lua, rocks.toml(from rocks.nvim) - i.e. not dependencies of a plugin, but dependencies of a user's configuration.

If yes, then I have following questions.

In an ideal world, when all plugins have properly defined pkg.json and use version tags, the current spec probably fits well. However, it is impossible to go from 0 to 100 immediately. So users would have to specify configuration themselves for the plugins they use. This would include:

1. Directory to install to (e.g. catpuccin/nvim would need to be changed to a valid name)
2. Branch to track. User may have commit hash as a revision, but commit can be part of history of multiple branches. So if they run update with their package manager, what branch should it pull?
3. Local version (I see that version field can use file://, however I don't understand the point of it. Rather, the key of the dependency should allow file://, which is now "Only support commit-id, tags, and HEAD"
4. Install to start or opt
5. Hooks (#23)
6. Probably some other properties of plugin_spec implemented by current package manages?

[justinmk]

i.e. not dependencies of a plugin, but dependencies of a user's configuration.

Yes. Users can specify their plugins in a local pkg.json.

whether it should play a role of lazy-lock.json

Lockfile is tracked in https://github.com/neovim/packspec/issues/47

users would have to specify ... 1. Directory to install

This is defined by the plugin manager. Intentionally not part of the spec, because it's target-dependent. Do you see a problem with that?

2. Branch to track.

I believe any git ref can be expressed in the version, though this is basically the one thing blocking this project: I need to decide whether we should deviate from NPM's version spec (which is pretty nasty).

I think probably the answer is "yes, deviate".

3. Local version (I see that version field can use file://, however I don't understand the point of it. Rather, the key of the dependency should allow file://, which is now "Only support commit-id, tags, and HEAD"

That might be something inherited from NPM. May need to revisit (see above).

4. Install to start or opt

I think the conclusion by the vim/nvim ecosystem is "neither" or "doesn't matter". It's out of scope for packspac. Nvim/Vim plugin managers need to manage 'runtimepath' (and maybe 'packpath').

5. Hooks (Post-install hook #23)

NPM has a spec around this. scripts, pre*, post*.

6. Probably some other properties of plugin_spec implemented by current package manages?

Part of the work of packspec is to leave target-dependent decisions up to the target. The goal here is, narrowly, to allow dependencies + versions to be specified; everything beyond that is out of scope.

[sarmong]

I am asking all of this because I see flaws in all current plugin managers, as they don't have easy access to all plugin specs from the start.

• Lazy - has access to all plugin specs on load, but takes control over user's config entirely, which is a big downside for me
• Mini.deps - benefit that user can have flat config with no magic and take control over plugin loading with .use. However, since the plugin manager doesn't know about all plugins ahead, this causes plugins to install synchronously one by one.
• Pckr (and mini.deps can be used like this too) - have all plugin definitions in one place separate from their configs. Downside - it is lua code, so it cannot be modified programmatically.

I am currently exploring a solution wherein user can call Install command, which will write plugin spec to json file and then gives control to loading of the plugin back to the user (for opt).

So, in my opinion, this may fix my dissatisfaction with current plugin managers - no magic, flat config, programmatically writable spec file and asynchronous installs.

Not sure if the issues I touched upon even matter to anyone, but I came to explore packspec to see if my solution can be made in a standardized manner, to not create another snapshot/dependencies/lockfile specification used only by me.

[Shougo]

I am asking all of this because I see flaws in all current plugin managers, as they don't have easy access to all plugin specs from the start.

It means you need spec repository like Emacs MELPA? https://melpa.org/

Certainly, having a central repository would be convenient for users to search and install plugins, but there are several issues:

• Who will register and update the plugins?
• Who will set up and maintain the repository?

Note: In the case of MELPA, the approval process seems to be manual.

[sarmong]

No, I didn't mean central repository, although this seems like an interesting idea.

I meant json file in user's config that holds user-defined plugin spec (commit/tag, branch, dir, hooks, opt/start, etc.). Basically the same thing that current plugin managers' plugin specs hold, just in a centralized json file over lua files in users' configs. Benefit is that it is programmatically writable and plugin managers can see full specs from the start.

[teto]

Not to hijack the thread but there is IMO a pretty successful POC based on rockspecs (the format used by luarocks) with luarocks.org holding probably > 400 neovim plugins (https://github.com/nvim-neorocks/nurr uploads 350 by itself). With https://github.com/nvim-neorocks/rocks.nvim you can Rocks install <PLUGIN> and it magically installs dependencies. This is also used in nixpkgs to automatically deduce dependencies.

My petpeeve and my main frustration with the plugin ecosystem now is that all plugins mandate some sort of setup when there shouldn't be any ! Many plugins require empty require'freaking-plugin'.setup() calls to even work ! So I've got this wonderful UI where I can install/remove at will plugins but it's of no use since afterwards I've got to add some silly configuration. One of neovim goal was is to make vim more approachable and work out of the box and this trend is counter to that.

So packspecs might do more but a lot could be accomplished first by the usage of vim builtins (autoload and so on).

[Shougo]

My petpeeve and my main frustration with the plugin ecosystem now is that all plugins mandate some sort of setup when there shouldn't be any ! Many plugins require empty require'freaking-plugin'.setup() calls to even work ! So I've got this wonderful UI where I can install/remove at will plugins but it's of no use since afterwards I've got to add some silly configuration. One of neovim goal was is to make vim more approachable and work out of the box and this trend is counter to that.

I don't think this is absurd. The fact that plugins work when users write configurations aligns with my philosophy that "users should handle all settings". If plugins were to work automatically upon installation, there is a risk that users wouldn't be able to tell which plugins are active just by looking at the configuration files.

[teto]

Just to make things clear, I dont contest that some plugins require configuration but 80% could happily work without a config out of the box.

If plugins were to work automatically upon installation, there is a risk that users wouldn't be able to tell which plugins are active just by looking at the configuration files.

If you dont use the plugin, dont install it ?! or install it in packpath's opt/. Also my beef with setup is that it's a require"plugin".setup() so once you uninstalled the plugin it triggers an error. Much better is to have the config in vim.g.MYPLUGIN_config. While I am less active on the main neovim repo, I test out lots of plugins for packaging purposes/help and having to constantly add/remove setup lines is irritating. https://github.com/nvim-neorocks/rocks-config.nvim/ alleviates this a bit but I can't always use it.

[brianhuster]

If plugins were to work automatically upon installation, there is a risk that users wouldn't be able to tell which plugins are active just by looking at the configuration files.

I think people rarely need that, the only use case I can think of is debugging, but if I need to, I would rather use a comand that is a wrapper of

print(table.concat(vim.api.nvim_list_runtime_paths(), '\n'))

An alternative choice to disable a plugin for a session would be just comment out part of the config code that declare the plugin (lazy.nvim supports that since it uses runtimepath by default)

[brianhuster]

Btw, why is repository a required field? If version is not in the spec because it can be queried from Git, isn't repository the same?