Poetry package listing fails for nested/non-root pyproject.toml projects (`poetry show` runs with wrong cwd)

Comienza en src/managers/poetry/poetryPackageManager.ts, especialmente en getDirectPackageNames() y getPoetryCwd(), y después lee poetryPackageManager.unit.test.ts y su aserción existente sobre el directorio de trabajo del proceso. Sigue cómo se resuelven el proyecto registrado y el entorno para proyectos anidados. Estará terminado cuando ambos comandos poetry show utilicen el directorio del proyecto registrado y las pruebas unitarias cubran ese comportamiento de cwd.

Environment

• vscode-python-envs version: 1.36.0
• OS: Linux (devcontainer, linux-arm64)
• Poetry: 2.4.3

Description

When a Poetry project is registered via python-envs.pythonProjects but is not at the workspace root (e.g. a monorepo with scripts/pyproject.toml), the "Manage Packages" package listing fails with:

poetry: Poetry could not find a pyproject.toml file in <extension host cwd> or its parents

Root cause (found in source)

PoetryPackageManager.getDirectPackageNames() (src/managers/poetry/poetryPackageManager.ts) builds PoetryShowTopLevelCommand without ever passing a cwd:

const showTopLevelCmd = new PoetryShowTopLevelCommand({
    pythonExecutable: poetry,
    log: this.log,
});

This means poetry show --no-ansi --top-level always 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 test poetryPackageManager.unit.test.ts: "direct package listing inherits the process working directory" asserts runPoetryStub.firstCall.args[1] === undefined.

fetchPackagesFromTool() (used for plain poetry show --no-ansi) does compute a cwd via getPoetryCwd(), but that logic only reliably resolves when api.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 empty matchingDirectories set (and thus undefined cwd) depending on how the workspace-root's own resolved environment compares.

Repro

1. Monorepo with pyproject.toml only in a subfolder, e.g. scripts/pyproject.toml.
2. Add to .vscode/settings.json:

   "python-envs.pythonProjects": [
     { "path": "scripts", "envManager": "ms-python.python:poetry", "packageManager": "ms-python.python:poetry" }
   ]
   

3. Open "Manage Packages" for the scripts project's Poetry environment.

Expected

poetry show commands run with cwd set to the registered project directory (scripts/).

Actual

Both poetry show --no-ansi --top-level and poetry show --no-ansi fail with "could not find a pyproject.toml", repeating every time packageWatchers triggers an auto-refresh.

Suggested fix

• Pass cwd (resolved from the project associated with environment, e.g. via api.getPythonProject(environment.environmentPath) or similar) into PoetryShowTopLevelCommand in getDirectPackageNames().
• In getPoetryCwd(), prefer resolving cwd from the actual project that owns the environment (e.g. via reverse lookup by environment path) rather than only matching by envId.id equality across all projects.