Repository navigation
Poetry package listing fails for nested/non-root pyproject.toml projects (poetry show runs with wrong cwd) #1779
Description
Activity
Also: the
${workspaceFolder}variable is not resolved in thepathproperty ofpython-envs.pythonProjects.${workspaceFolder}/scriptsdoes not result in an absolute path, but in a verbatim${workspaceFolder}/scriptsentry in thePython Projectspane."python-envs.pythonProjects": [ { "path": "${workspaceFolder}/scripts", "envManager": "ms-python.python:poetry", "packageManager": "ms-python.python:poetry" } ]- changed the title
[-]Poetry package listing fails for nested/non-root pyproject.toml projects (poetry show runs with wrong cwd)[/-][+]Poetry package listing fails for nested/non-root pyproject.toml projects (`poetry show` runs with wrong cwd)[/+]on Sep 11, 2026 Longer-term suggestion: carry the Python project URI explicitly through package operations rather than trying to infer the project solely from the environment. The Python Projects view already has the project URI (
projectView.ts), but thePackageManagermethods currently receive only aPythonEnvironment. An environment can live outside its project or be shared by multiple projects, sogetPythonProject(environment.environmentPath)and reverse-matching by environment ID cannot always identify the Poetry project whosepyproject.tomlshould be used.Consider an optional project/scope URI in the relevant package-operation context (preserving environment-only callers), propagated through package listing, refresh, direct-dependency lookup, and add/remove. Poetry would run each project-dependent command with
cwdset to that project directory. For calls without an explicit project, resolve only when the environment maps to one unambiguous Poetry project; otherwise report the missing/ambiguous context instead of inheriting the extension-host cwd. Cache keys would also need to include project identity where results depend on the project, so two projects sharing an environment do not overwrite each other.A regression test with two Poetry projects sharing an external virtualenv would exercise the ambiguity that an environment-only lookup cannot solve. This is a longer-term API design point; the immediate cwd bug can be addressed independently.
Environment
Description
When a Poetry project is registered via
python-envs.pythonProjectsbut is not at the workspace root (e.g. a monorepo withscripts/pyproject.toml), the "Manage Packages" package listing fails with:Root cause (found in source)
PoetryPackageManager.getDirectPackageNames()(src/managers/poetry/poetryPackageManager.ts) buildsPoetryShowTopLevelCommandwithout ever passing acwd:This means
poetry show --no-ansi --top-levelalways inherits the extension host process's own cwd (in a remote/devcontainer setup this is the vscode-server install directory), not the project directory. This is confirmed intentional by the existing unit testpoetryPackageManager.unit.test.ts: "direct package listing inherits the process working directory" assertsrunPoetryStub.firstCall.args[1] === undefined.fetchPackagesFromTool()(used for plainpoetry show --no-ansi) does compute a cwd viagetPoetryCwd(), but that logic only reliably resolves whenapi.getPythonProjects()returns exactly one project. Since VS Code always implicitly adds the workspace root as a project (PythonProjectManagerImpl.getInitialProjects()), any repo with a registered non-root Poetry project (e.g.scripts/) ends up with 2+ projects, forcing the "match by environment identity" branch — which can return an emptymatchingDirectoriesset (and thusundefinedcwd) depending on how the workspace-root's own resolved environment compares.Repro
pyproject.tomlonly in a subfolder, e.g.scripts/pyproject.toml..vscode/settings.json:scriptsproject's Poetry environment.Expected
poetry showcommands run with cwd set to the registered project directory (scripts/).Actual
Both
poetry show --no-ansi --top-levelandpoetry show --no-ansifail with "could not find a pyproject.toml", repeating every timepackageWatcherstriggers an auto-refresh.Suggested fix
cwd(resolved from the project associated withenvironment, e.g. viaapi.getPythonProject(environment.environmentPath)or similar) intoPoetryShowTopLevelCommandingetDirectPackageNames().getPoetryCwd(), prefer resolving cwd from the actual project that owns the environment (e.g. via reverse lookup by environment path) rather than only matching byenvId.idequality across all projects.