microsoft / microsoft/vscode-python-environments

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

未关闭
#1,779 1 条评论 1 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

triage-needed
主要语言
TypeScript
星标
138
派生
62
平均合并
1 天 4 小时
30 天内合并 PR
35

描述

### 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 or its parents
```

### Root cause (found in source)
`PoetryPackageManager.getDirectPackageNames()` (`src/managers/poetry/poetryPackageManager.ts`) builds `PoetryShowTopLevelCommand` without ever passing a `cwd`:

```ts
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`:
```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.

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

调研方向

从 src/managers/poetry/poetryPackageManager.ts 开始,重点查看 getDirectPackageNames() 和 getPoetryCwd(),然后阅读 poetryPackageManager.unit.test.ts 及其中现有的进程工作目录断言。跟踪嵌套项目的已注册项目和环境是如何解析的。当两个 poetry show 命令都使用已注册项目目录,并且单元测试覆盖该 cwd 行为时,即视为完成。

由索引模型根据 Issue 内容生成。

评估

技术栈
python, typescript
领域
developer-experience, tooling
Issue 类型
缺陷
难度
4/5
预计耗时
3-5 天
活跃度
活跃
描述清晰度
描述清楚
新手友好度
74/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。