Feature request: Vscode extension - support offline installation with local Python environment

[danieltomasz]

Use case

I'm working in an offline/restricted network environment where:

• I have a local PyPI mirror (can install packages)
• No access to github.com (cannot download standalone Python builds)
• I have a local Python 3.12 venv with python-lsp-server and python-lsp-ruff already installed

I'd like to use the marimo VSCode extension in this setup.

Current behavior

The extension (v0.10.4) tries to install ruff via bundled uv with UV_PYTHON=3.10, which attempts to download a standalone Python 3.10 build from github.com/astral-sh/python-build-standalone. This fails in my environment, and the extension doesn't fall back to using the local Python interpreter or existing LSP packages.

Suggestion

It would be great if the extension could:

• Reuse an existing python-lsp-server / python-lsp-ruff from the user's environment
• Or use the available Python interpreter instead of requiring a specific Python 3.10 download
• Or make the Python version / LSP source configurable

This would make the extension usable in air-gapped or restricted network environments.

[manzt]

Thanks for the request. If we had some config to point to a custom ruff/ty binary (marimo.ruff.path) would that help?

Our server setup is tied to the ruff/ty binaries, so i'm not sure we could support generic python-lsp-server.

[danieltomasz]

@manzt Yes, marimo.ruff.path would help — I have ruff/ty and other needed packages installed locally and can point to them.

To clarify my setup: the machine is offline with no access to the internet, only to a local PyPI mirror on our network. I don't use uv — I use a custom virtualenv setup to create my local environments.

I can download and manually install VSCode extensions (like the standalone ruff extension), so ideally extensions should be self-contained or rely on other extensions that I can install separately.

[manzt]

Thanks for the context on your setup — that makes sense.

so ideally extensions should be self-contained or rely on other extensions that I can install separately.

Agreed in this ideal. Unfortunately, today external extensions (Ruff, ty/Pyright, etc.) don't understand marimo's cell execution model. They assume top-to-bottom execution, but marimo cells execute based on a dependency graph. This causes false positives everywhere (unused imports, undefined names, etc.), which is a poor first experience for users (#185, #236).

To address this, we introduced a "managed" mode that runs its own instances of Ruff/ty with middleware that reorders cells topologically before analysis (#262, #337, #344).

We're working upstream to fix this properly. I've filed a proposal to the LSP spec for notebook cell analysis ordering, and we're coordinating with Astral on adding metadata support to Ruff/ty (astral-sh/ty#2100, astral-sh/ruff-vscode#893). Until that lands, the managed approach is the best trade-off we've found.

That said, I'm going to work on adding marimo.ruff.path / marimo.ty.path config options so you can point to your local binaries as a workaround for your air-gapped setup.

[manzt]

This is addressed in #414 (merged) and will be in the next release. Going forward, the easiest setup for offline/restricted environments is to install the charliermarsh.ruff and astral-sh.ty companion extensions. The marimo extension will discover their bundled binaries automatically, so uv pip install never runs for ruff/ty.

Alternatively, if you have the binaries installed locally, you can point to them directly:

{
  "marimo.ruff.path": "/usr/local/bin/ruff",
  "marimo.ty.path": "/usr/local/bin/ty"
}