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

[mrcjkb]

Discussed in #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 luarocks/luarocks#1684

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

[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:

[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:

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

[vhyrro]

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.