add `[tool.pyright]` section when `uv init`

[bnjox]

trafficstars

can we add this block when we do uv init

[tool.pyright]
venvPath = "."
venv = ".venv"

• It helps avoid creating a pyrightconfig file for small (or all) projects
• Helps avoid always adding it manually or creating the pyrightconfig file to add extra config.

[my1e5]

If you have a specific configuration you want to use, you can set up a command. For example

$ uv init foo && cd foo && echo $'\n[tool.pyright]\nvenvPath = "."\nvenv = ".venv"' >> pyproject.toml

You could put this as a command in a .zshrc or .bashrc file

init_uv_pyright() {
    uv init "$1" && cd "$1" && echo $'\n[tool.pyright]\nvenvPath = "."\nvenv = ".venv"\n' >> pyproject.toml
}

then run

$ init_uv_pyright foo

$ cat pyproject.toml
[project]
name = "foo"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.12"
dependencies = []

[tool.pyright]
venvPath = "."
venv = ".venv"

[bnjox]

that could work, but having to setup a custom script just for that is a lot. what if the tool could either make an option or add it in like we had for the build backend (previously)

[MikeHart85]

Assuming you want correct lsp library resolution in your editor, try activating the venv before starting the editor:

$ . .venv/bin/activate
(venv) $ nvim .

Doing it this way has the added benefit that pyright also correctly resolves standard library imports, particularly when a non-system Python install is being used:

$ uv init --python=3.8
$ uv sync
$ nvim pyproject.toml  # your tool.pyright edit
$ nvim hello.py

from pathlib import Path  # try go definition on Path

You'll find it either resolves to the system Python library version or, more likely, the typeshed-fallback pyi that pyright ships with. Either way, this will give partially incorrect hints for that Python version.

If you activate the venv instead, without edits to pyproject.toml, it will correctly resolve to ~/.local/share/uv/[...]/lib/python3.8/pathlib.py.

Adding this config block to pyproject.toml would break correct resolution for everyone collaborating on the project, even if they activate their venv before starting their editor.

[bluss]

@MikeHart85 I think that you're right this is a "bug" in pyright, but I can't find that it's tracked. The fork basedpyright has an issue tracking this.

I think VS Code doesn't need this setting because it configures the LSP with pythonPath or extraPaths instead.

I use neovim and have decided to do the same thing - configure basedpyright with pythonPath/extraPaths per project dynamically - detect a local .venv and query that python for its paths, and use that. That both removes the need for the venv/venvPath configuration, has no need for venv activation, and fixes that bug with jump-to-definition on standard library items.

It's more complicated, but it also allows correct include paths with multiple projects open in the same editor instance.

@sparrowsl: I think the venv/venvPath settings are good, better than requiring environment activation, but IMO just a stepping stone on the way to a fully satisfactory configuration. Even better is to not need those settings at all..

[MikeHart85]

Yeah, it definitely smells like a pyright bug. It has everything it needs to figure out the correct location with venvPath/venv set, but just doesn't.

Neovim users could also consider https://github.com/linux-cultist/venv-selector.nvim, which has no trouble finding the .venv that uv generates, and remembers which venv to use on a per project basis. However, it currently has the same problem as setting the venPath/venv in pyproject.toml, presumably because it effectively does the same thing and so runs into the same pyright bug.

Perhaps it could be updated to set pythonPath/extraPaths instead, as you suggest. But that feels like a workaround for a bug that shouldn't exist. Really, it's up to based/pyright to fix this properly.

[konstin]

We try to avoid adding configuration for external tools in uv. There are some workarounds in this thread, otherwise I recommend raising this with pyright.