For instance, allowing :Rocks install something opt=trueft=markdown and feeding that directly into the toml.
We already do that[^1] :wink:
[^1]: As long as the extensions know how to parse args that rocks.nvim doesn't know about.
So far, only rocks.nvim and rocks-git.nvim know how to parse args.
What could be tricky is coming up with a good API for args that are lists:
The last one is more concise, but also more brittle: If someone passes in ft=markdown, it would be added to the install_args as long as rocks-lazy.nvim doesn't register an arg parser.
should we instead support an [env] section in the toml, which would modify vim.env?
Luarocks won't pick up GIT2_DIR from an environment variable. It has to be passed as an arg to install.
Since this is more of an edge case, I think we don't need to prioritise passing install_args via :Rocks install initially.
We already do that[^1] :wink:
[^1]: As long as the extensions know how to parse args that rocks.nvim doesn't know about. So far, only rocks.nvim and rocks-git.nvim know how to parse args.
What could be tricky is coming up with a good API for args that are lists:
or
or, assuming any args that rocks.nvim can't parse are
install_args
:The last one is more concise, but also more brittle: If someone passes in
ft=markdown
, it would be added to theinstall_args
as long as rocks-lazy.nvim doesn't register an arg parser.Luarocks won't pick up
GIT2_DIR
from an environment variable. It has to be passed as an arg toinstall
.Since this is more of an edge case, I think we don't need to prioritise passing
install_args
via:Rocks install
initially.Originally posted by @mrcjkb in https://github.com/nvim-neorocks/rocks.nvim/issues/439#issuecomment-2200585803