Editor support · instamix

imix lsp is a language server for the Ansible side of a script: problems where you wrote them, your roles installed, and Ansible inside the strings.

imix lsp is a language server for the Ansible side of a script. Run it next to your usual Python server; it only acts on files that import instamix.

A playbook written in Neovim: completion inside the string, an ansible-lint problem on its task and gone once fixed, and module docs on hover. make demo records it again.

What it does#

Problems where you wrote them. On open and on save the script runs in dump mode (generate, run and main do nothing, so no host is touched). Its tree goes to ~/.cache/instamix/lsp/, and ansible-lint and your checks run over it. Each problem lands on the line that declared the file: inside a file() string, it’s the exact spot; for role(tasks=[...]) and other helpers, it’s the call; for include(), both the call and the included file. Exceptions show up where the script raised them.
Your roles and collections, installed. The collections and roles the script declares are installed into that tree, as install would, so they complete and ansible-lint resolves them. The tree’s galaxy.lock records what was installed for which requirements; they are installed again only when your requires_collection() and requires_role() calls change, and then what the lock lists is removed first. The galaxy option turns it off.
Ansible inside strings. In file("....yml", """..."""), including the """.encode() form that import writes, completion, hover and go-to-definition come from the Ansible language server. Each string is mirrored at its path in that same tree, so it sees your roles and ansible.cfg.

The Ansible language server is taken from the ansibleServer option, $INSTAMIX_ANSIBLE_SERVER, ansible-language-server on PATH (npm i -g @ansible/ansible-language-server), or the copy inside the Red Hat Ansible VS Code extension. Without one, you still get the diagnostics.

VS Code#

Build the extension in editors/vscode (npm install && npx vsce package), then run code --install-extension instamix-0.1.0.vsix. It picks up the Red Hat Ansible extension’s server by itself.

It also highlights those strings when the call opens on one line (file("site.yml", """): as Ansible, with keywords, when: conditions and {{ jinja }}, using the Red Hat extension’s grammars; as plain YAML without them.

Neovim#

For Neovim 0.11 or newer, see editors/nvim in the source. With LazyVim, one line loads it from the repo:

-- ~/.config/nvim/lua/plugins/instamix.lua
return dofile(vim.fn.expand("~/Projects/instamix/editors/nvim/lazy.lua"))

That enables the server and adds tree-sitter highlighting: each string as the file it declares (YAML, shell, Jinja, …), and Jinja in YAML values that use {{, {% or {# and in when: conditions (in every YAML file). The server itself colours Ansible keywords, modules and their options inside the strings. Inside a string, indentation follows the declared file too (ts=2 sw=2 expandtab for YAML), configurable per filetype.

Options#

VS Code settings instamix.*, or init_options in Neovim:

Option	What it does
`profiles`	The profiles to activate, like `-p`.
`execute`	Run scripts; default on.
`lint`	Run ansible-lint; default on.
`galaxy`	Install the script’s collections and roles into the tree.
`ansibleServer`	Where the Ansible language server is.
`semanticTokens`	Default on. The VS Code extension turns it off, because VS Code takes semantic tokens from only one server per file and they would replace Pylance’s.