Description
Related to posit-dev/positron#7605
Consider the current VS Code experience with Quarto. I'm pretty sure it's:
- Install VS Code Extension for Quarto
- Separately, install the Quarto binary
- VS Code Extension for Quarto will find the Quarto binary
In Positron, we streamline this a bit by:
- Including the VS Code Extension for Quarto as a bootstrapped extension
- Also shipping a Quarto binary with Positron itself
But this feels a bit backwards to me for a few reasons
The Extension should ship the binary
In Air, we create platform specific VS Code Extension files (vsix's) and we ship the air binary in the Air VS Code Extension.
https://github.com/posit-dev/air/blob/main/.github/workflows/release-vscode.yml
https://code.visualstudio.com/api/working-with-extensions/publishing-extension#platformspecific-extensions
All Positron has to do is slurp up the right platform specific vsix and include it in the release build of Positron.
The big benefit of this is that in VS Code, your initial experience with Air is:
- Install VS Code Extension for Air
- ...you're done.
We aren't alone in this, we got the idea from rust-analyzer, ruff, and biome.
Currently, the binary can be out of sync with the Extension
I imagine this isn't a huge issue, but in theory the quarto binary could be out of sync with the VS Code Extension for Quarto. Imagine:
- User downloads VS Code Extension for Quarto
- User downloads the Quarto binary
- 6 months go by, the VS Code Extension for Quarto has been auto-updating itself. There is some breaking change that puts it out of sync with the Quarto binary
We don't have this problem as much with Air. When the Air VS Code Extension auto-updates, the user gets a new bundled Air binary too. So things mostly stay in sync.
There are also a few things we should consider adding as features if the Quarto extension was to bundle the binary itself.
Opt-ing out of a bundled Quarto binary
If we did do this, we'd want users to have a way to opt-out of the bundled Quarto binary, instead preferring one on their PATH, or in QUARTO_PATH, or by providing an explicit file path to a Quarto binary.
In Air, we have a VS Code configuration option for this called executableStrategy. It defaults to the bundled binary, but you can specify alternatives:
https://github.com/posit-dev/air/blob/ff8edf34f7fd84c75654730cde2d2c565dc8a296/editors/code/package.json#L84-L105
Project specific Quarto binaries
This is probably its own issue, but it would be incredibly nice if a user could somewhere specify that they want, say, quarto-version: 1.7.4, and have the VS Code Extension automatically recognize that and download and use the right binary.
Imagine you have:
- Project A tied to
quarto-version: 1.74 - Project B tied to
quarto-version: 1.85
Imagine how awesome it would be if you could just open Project A or Project B and feel confident that the right version of the quarto binary was being used.
We don't have a great story for this in Air yet either, but Ruff does have a great story for this. Because Ruff is on PyPi as a wheel that basically just ships the binary, they specify a version of Ruff in their pyproject.toml/requirements.txt and then it gets installed by uv into their project specific virtual environment, and their VS Code Extension is smart enough to look into their virtual environment first to try and find a version of Ruff to use. So, boom, they instantly have per-project Ruff versioning. Beautiful, this is truly peak software design.