Open mrcjkb opened 1 week ago
Some potential downsides:
Rocks sync
?
luarocks install
for any rock that has a version constraint, without checking if it's outdated.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.
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:
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.
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.
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?
Discussed in https://github.com/nvim-neorocks/rocks.nvim/discussions/403
Blocked by https://github.com/luarocks/luarocks/issues/1684