Introduce engines

[numToStr]

Problem

When I hear dependency I think of something third party thingy and putting neovim identifier inside it maybe is not a great idea. As this is the editor for which we are making the spec.

Solution

I would suggest to introduce a top level table named engines or something which can hold the first party version constraints like neovim itself.

engines = {
    neovim = ">=0.7.0",
    rpc = "0.7.0",
    -- lua = "LuaJIT",
    -- treesitter = "0.9.0",
    -- vim = ">8.2"
}

FAQ

What's this engines table can hold?

I am only considering first party components like neovim itself but other things can be added if the need arises.

Why name it engines?

This name is coming from package.json spec but it can be changed to better complement the neovim community.

Prior

• package.json spec - https://docs.npmjs.com/cli/v8/configuring-npm/package-json#engines

---

This could also effect #19

[ii14]

This is pretty much a duplicate of #19

neovim is not top-level, it's under dependencies. What I was thinking is just leaving those "special" dependencies, "engines" or whatever you want to call it under dependencies directly, and packages or external dependencies being a nested dictionary/table, like this:

dependencies = {
  neovim = "...",
  packages = {
    -- ...
  },
  rocks = {
    -- ...
  },
  external = {
    -- ...
  },
}

[numToStr]

Yes, I saw that but I am also hoping to cover other inbuilt things versions like RPC or even vim. If this could be covered in #19 then there is no need for this.

[lewis6991]

Just as Neovim doesn't have feature flags, we should minimise what handles we want to specify. For almost everything, the version of Neovim will be sufficient. There is no need to unnecessarily add bloat without good reason.

[ii14]

@numToStr I'm not against this, but I think you can just add them directly to dependencies.

[mjlbach]

So, RPC/vim I think should probably not be included. I could see an argument being made for checking the version of treesitter and luajit, but I don't think there is a real world usecase for the former, and the presence of the latter can be checked by vim.jit

[numToStr]

@ii14 Defining neovim under dependencies felt kinda odd too me.

If I talk about others, rust also recently introduced a special rust-version field.

---

@mjlbach Yes. This is just a sketch, we can surely decide which fields should be defined.

[ii14]

So, RPC/vim I think should probably not be included.

@mjlbach Even if it appears useless and is not supported by the spec right now, I don't think we should rule out the possibility of something like this being useful in the future, or package managers just adding their own extensions to the spec, like some package manager for vim adopting this and adding vim field.

[justinmk]

engines field also suggested in #41