packspec icon indicating copy to clipboard operation
packspec copied to clipboard

Introduce `engines`

Open numToStr opened this issue 4 years ago • 8 comments

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 https://github.com/nvim-lua/nvim-package-specification/issues/19

numToStr avatar Mar 29 '22 16:03 numToStr

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 = {
    -- ...
  },
}

ii14 avatar Mar 29 '22 16:03 ii14

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.

numToStr avatar Mar 29 '22 16:03 numToStr

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.

lewis6991 avatar Mar 29 '22 16:03 lewis6991

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

ii14 avatar Mar 29 '22 16:03 ii14

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

mjlbach avatar Mar 29 '22 16:03 mjlbach

@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.

numToStr avatar Mar 29 '22 17:03 numToStr

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.

ii14 avatar Mar 29 '22 17:03 ii14