Working with Python in Zed isn’t where it should be. Virtual environments often slip through the cracks, configuration can be confusing, and the onboarding experience can stumble in small but frustrating ways. This year, we've made Python a priority as part of our Language‑specific Initiatives.
Now when you use Python in Zed, you get:
- Better virtual environment detection: Zed now detects and manages venvs automatically with a toolchain selector.
- Monorepo ready: Each sub-project gets its own toolchain, tracked via
pyproject.toml.
- More reliable servers: Zed runs separate language servers per toolchain, keeping completions, jumps, and hovers accurate.
- Basedpyright as the default LSP: We now support ty and Ruff out of the box, with support for Pyrefly via an extension.
Read on to learn more about what we improved, and how.
The Language Server Protocol (LSP) makes important features possible, but we don't love the status quo. Other editors feel more complete because they integrate these servers in more thoughtful ways and reduce configuration overhead. Our goal is to match that ease, so you can write code without worrying about configuration.
Python, in particular, exposes the limits of treating LSP as the whole story. The Python ecosystem is sprawling: multiple package managers (pip, poetry, conda), competing virtual environment tools, monorepos with overlapping dependencies, and a growing set of language servers with different strengths. A language server alone doesn’t know which interpreter you’re using, whether your venv is active, or how to connect that context to completions, jump-to-definition, or debugging. That’s why Python users in many editors end up juggling config files, tweaking paths, or fighting with broken venv detection. We don't love that!
Take virtual environments. Until earlier this year, Zed had no notion of what the active virtual environment was (except for a bit of code that handled auto-activation of venv in terminal). Users had to dig into config files to point Zed at the right interpreter. Horrid.
This is why we've introduced a toolchain selector; it lets each language provide a set of toolchains, which you can then choose from. We were specifically interested in a more generic solution than a "venv selector" because we don’t want code paths that exist solely to paper over Python’s intricacies. This benefits other languages that have their own flavor of toolchains (like Rust or JavaScript/TypeScript), even if they're not as in-your-face as Python is.
The selector itself runs on Microsoft’s python-environment-tools library1 — the same one behind venv detection in Visual Studio Code. Thanks to that, this blog doesn’t need a whole section about Zed failing to detect some obscure environment. Most issues we’ve seen are rooted in our own codebase.
That said, the selector still has rough edges. Serialization in particular needs work. Today, your toolchain choice may or may not persist as expected. We plan to make those choices more reliable.
Perfect venv handling on its own doesn’t make Zed a perfect Python environment. Developers working in monorepos often need multiple venvs, one per sub‑project. They expect to be able to select disjoint toolchains. That turned out to be trickier than it sounds.
Developers working in monorepos often need more than one virtual environment: one per subproject. But Zed originally tied a project to a single toolchain, which broke down as soon as you needed multiple. To fix this, we introduced the manifest tree. Zed now tracks the location of manifests across your worktree — for Python, that’s the nearest pyproject.toml to the file you’re editing. When you select a venv for one file, Zed ties that choice to the manifest’s location, so every file in that subproject shares the same toolchain. That way, you can use different toolchains across subprojects, without mixing them inside a single one.
You can't handle more than one... or can you?
Could we patch the servers to juggle multiple toolchains? Maybe, but the complexity would explode. We think it belongs in the client instead. That’s why Zed now runs a separate server for each toolchain. Each project stays isolated, and the servers can remain focused on doing their job well. Complexity on our side, consistency on yours.
The change to run multiple language servers landed in version v0.201. We are excited to get your feedback on how it works.
We’re betting on Astral to shake up the Python ecosystem. There, we said it. ty already solves performance issues we’ve seen with other servers. We built an extension for it, and our plan is to pull Ty into Zed’s core so you won’t need to install anything. It’ll start off disabled by default, but we expect to flip it on in the future.
We’re also paying attention to pyrefly, and we still support Pyright and Pylsp. Those aren’t going away, and we’ll keep them as options to ease your transition. But we hope ty succeeds. It’ll be easier for us to interact with a server written in Rust, and easier for you to get fast, reliable results.
We will continue improving the Python experience in Zed, and we're excited to introduce notebooks in 2026. We want to make Zed a tool Pythonistas want to reach for, not one they simply tolerate.
We want to hear from you: how do these improvements feel? What can we make better? Join this GitHub discussion and let us know -- seriously.
- PET is also used to power virtual environment search within Visual Studio Code. ↩
Recent Posts
Check out similar blogs from the Zed team.
Looking for a better editor?
You can try Zed today on macOS, Windows, or Linux. Download now!
We are hiring!
If you're passionate about the topics we cover on our blog, please consider joining our team to help us ship the future of software development.
Instagram Engineering
Shopify Engineering