rocks.nvim icon indicating copy to clipboard operation
rocks.nvim copied to clipboard

[Feature] Support version constraints (`~>`, `>=`, etc)

Open mrcjkb opened this issue 1 year ago • 6 comments

Discussed in https://github.com/nvim-neorocks/rocks.nvim/discussions/403

Originally posted by rktjmp June 22, 2024 Does rocks.nvim support semver constraints? I assumed it would be delegated to luarocks, which does appear to support constraints (under dependencies) but norg = "~> 7" (and variations) fails with a "version number '~> 7' could not be parsed" error during a Rocks sync.

Is it a planned feature?

Blocked by https://github.com/luarocks/luarocks/issues/1684

mrcjkb avatar Jun 22 '24 10:06 mrcjkb

Some potential downsides:

  • Higher complexity for Rocks sync?
    • Maybe a non-issue since we could simply run luarocks install for any rock that has a version constraint, without checking if it's outdated.
  • Like scm rocks, such rocks cannot be locked.

We could also add a separate (not to be edited) installed_version field for any rock where the version is a constraint. This would solve both problems, but could lead to undefined behaviour if users modify it.

mrcjkb avatar Jun 22 '24 10:06 mrcjkb

To add some complexity to the request, a Rocks outdated feature is useful with this, so you can see when your constraint is potentially outdated, eg the "latest" column below:

image

rktjmp avatar Jun 22 '24 10:06 rktjmp

To add some complexity to the request, a Rocks outdated feature is useful with this, so you can see when your constraint is potentially outdated, eg the "latest" column below:

image

I've been thinking of writing a small language server for rocks.toml that provides diagnostics and code actions.

mrcjkb avatar Jun 22 '24 11:06 mrcjkb

I don't even think a language server is needed, just some smart adaptors to the vim.lsp protocol, unless that's what you meant. I do agree that an LSP interface for rocks.toml would be incredible for general UX.

vhyrro avatar Jun 26 '24 10:06 vhyrro

With https://github.com/nvim-neorocks/rocks.nvim/pull/459, you will by default be prompted if an update will have a breaking change. I'm not sure if there's really a strong use case for specifying things like ~> 1.5 or ~> 1,5.5.

Given #459 combined with the ability to pin rocks, is there even a need for this at all?

mrcjkb avatar Jul 04 '24 21:07 mrcjkb

This will be closed once #539 has been implemented, as rocks supports installing with version constraints.

mrcjkb avatar Dec 20 '24 15:12 mrcjkb