Bundled Pyright ignores pyrightconfig.json extraPaths — false-positive import errors for venv-only packages

[JsonDaRula69]

Problem

AFT's bundled Pyright LSP (~/.cache/aft/lsp-packages/pyright/, v1.1.410) does not resolve packages installed in a project virtualenv, producing false-positive Import "X" could not be resolved errors — even when pyrightconfig.json is correctly configured with venvPath, venv, and extraPaths.

Environment

• OS: macOS 15 (darwin)
• Python: 3.14.5 (via Homebrew)
• Project venv: .venv/ (created with python3 -m venv .venv)
• AFT LSP cache: ~/.cache/aft/lsp-packages/pyright/node_modules/pyright/ (v1.1.410)
• Package: aioslsk v1.6.3 installed in .venv/lib/python3.14/site-packages/

Reproduction

1. Create a Python project with a venv containing a package not in the system Python:

   python3 -m venv .venv
   .venv/bin/pip install aioslsk

2. Create pyrightconfig.json at the project root:

   {
     "venvPath": "/absolute/path/to/project",
     "venv": ".venv",
     "pythonVersion": "3.14",
     "include": ["src"],
     "extraPaths": ["/absolute/path/to/project/.venv/lib/python3.14/site-packages"],
     "reportMissingImports": "error"
   }

3. Import the venv-only package in a .py file:

   from aioslsk.client import SoulSeekClient

4. Run aft_inspect on the file — AFT reports:

   error Import "aioslsk.client" could not be resolved [Pyright]
   

Evidence that these are false positives

Both standalone Pyright and basedpyright resolve the imports correctly with the same config:

$ npx pyright --project pyrightconfig.json src/soulseek.py
0 errors, 0 warnings, 0 informations

$ basedpyright --project pyrightconfig.json src/soulseek.py
# (no import errors — only strictness warnings from basedpyright)

The package exists at the configured path:

$ ls .venv/lib/python3.14/site-packages/aioslsk/client.py
.venv/lib/python3.14/site-packages/aioslsk/client.py

What I tried

1. pyrightconfig.json with extraPaths (relative paths)

{ "extraPaths": [".venv/lib/python3.14/site-packages"] }

Result: AFT still reports import errors. npx pyright works.

2. pyrightconfig.json with absolute paths

{ "extraPaths": ["/Users/djtchill/Documents/Projects/CDJeez/.venv/lib/python3.14/site-packages"] }

Result: AFT still reports import errors. npx pyright works.

3. [tool.pyright] in pyproject.toml

[tool.pyright]
venvPath = "."
venv = ".venv"
extraPaths = [".venv/lib/python3.14/site-packages"]

Result: AFT still reports import errors.

4. .opencode/lsp.json — disable bundled pyright, enable basedpyright

{
  "lsp": {
    "basedpyright": { "priority": 100 },
    "ruff": { "priority": 90 },
    "pyright": { "disabled": true }
  }
}

Result: AFT diagnostics still say [Pyright] (not [basedpyright]), suggesting the bundled pyright is still being used despite the disabled: true config. The .opencode/lsp.json config may not be read by AFT's diagnostic engine, or AFT may need a restart to pick up LSP config changes.

5. .opencode/lsp.json — initialization options with extraPaths and pythonPath

{
  "lsp": {
    "basedpyright": {
      "priority": 100,
      "env": { "PYTHONPATH": "/path/.venv/lib/python3.14/site-packages" },
      "initialization": {
        "settings": {
          "python": { "pythonPath": "/path/.venv/bin/python3" },
          "basedpyright": { "analysis": { "extraPaths": ["/path/.venv/lib/python3.14/site-packages"] } }
        }
      }
    },
    "pyright": { "disabled": true }
  }
}

Result: AFT still uses bundled pyright, still reports import errors.

Current workaround

Targeted # type: ignore[import-not-found] on each affected import line:

from aioslsk.client import SoulSeekClient  # type: ignore[import-not-found]

This suppresses only the specific false-positive import errors on those lines — any other missing import in the file is still reported. This is surgical but fragile: if AFT later starts reading the config, these comments become unnecessary noise.

Expected behavior

AFT's bundled Pyright should read pyrightconfig.json (or [tool.pyright] in pyproject.toml) from the project root and resolve venv-installed packages via venvPath/venv/extraPaths. Alternatively, if AFT supports switching to a user-installed LSP (basedpyright), the .opencode/lsp.json disabled: true should prevent the bundled pyright from running.

Questions

1. Does AFT's diagnostic engine pass the workspace root to the bundled Pyright LSP? If not, Pyright won't find pyrightconfig.json.
2. Does .opencode/lsp.json pyright: { disabled: true } actually prevent AFT from using the bundled pyright? If not, is there another way to switch to basedpyright?
3. Is a session/AFT restart required for .opencode/lsp.json changes to take effect?

[JsonDaRula69]

Update: Installing to system/user Python does NOT fix the issue

Following up on the question of whether installing the package to system Python (instead of venv-only) would resolve the false positives — it does not.

What I tried

pip3 install --user --break-system-packages aioslsk

This installed aioslsk to ~/Library/Python/3.14/lib/python/site-packages/. Confirmed importable from system Python:

$ python3 -c "import aioslsk; print(aioslsk.__file__)"
/Users/djtchill/Library/Python/3.14/lib/python/site-packages/aioslsk/__init__.py

Standalone Pyright with no config at all resolves it from user site-packages:

$ cd /tmp && echo "import aioslsk" > test.py && npx pyright test.py
0 errors, 0 warnings, 0 informations

I also added the user site-packages path to pyrightconfig.json extraPaths:

"extraPaths": [
  "/Users/djtchill/Documents/Projects/CDJeez/.venv/lib/python3.14/site-packages",
  "/Users/djtchill/Library/Python/3.14/lib/python/site-packages"
]

Result

AFT's bundled Pyright still reports all 6 import errors. This confirms that AFT's Pyright is not reading pyrightconfig.json at all — it is not a matter of the package being in the wrong location. Neither venv site-packages nor user site-packages nor system site-packages are scanned by AFT's Pyright.

Conclusion

The root cause is that AFT's bundled Pyright does not receive or use the workspace root, so it never finds pyrightconfig.json. It also does not scan standard Python import paths (system, user, or venv site-packages). Installing packages to system Python is not a workaround.

Current workaround remains

Targeted # type: ignore[import-not-found] on each affected import line. I have uninstalled the user-level aioslsk to keep the system Python clean — the venv-only install is the correct setup.