• Add Python_pip_pyproject provider for PEP 621 pyproject.toml without lock files
• Resolve dependencies using pip install --dry-run --ignore-installed --report
• Implement workspace/monorepo support with lock file discovery and boundary detection
• Add comprehensive test coverage for pip provider and workspace scenarios

Register new pip pyproject provider

src/provider.js

New pip provider for PEP 621 pyproject.toml

src/providers/python_pip_pyproject.js

Add workspace detection and lock file discovery

src/providers/base_pyproject.js

Description

Base_pyproject now calls _getDependencyData() using lockFileDir rather than the provided manifest’s
directory, but Python_poetry derives its dependency data only from that passed directory and does
not use the parsed member pyproject. When a workspace member pyproject.toml relies on a poetry.lock
in a parent directory, dependency resolution can be performed against the parent project instead of
the requested member manifest, producing an incorrect SBOM.

Code

src/providers/base_pyproject.js[R351-352]

+		let lockFileDir = this._findLockFileDir(manifestDir, opts) || manifestDir
+		let { directDeps, graph } = await this._getDependencyData(lockFileDir, parsed, opts)

Evidence

_createSbom() reads/parses the requested manifest, but then switches the dependency-resolution
working directory to the lockfile directory (lockFileDir) before calling _getDependencyData(). The
Poetry provider ignores the parsed manifest entirely and runs its dependency commands using only the
passed manifestDir/cwd, so when Base_pyproject passes lockFileDir, Python_poetry has no way to scope
resolution to the originally requested member manifest.

src/providers/base_pyproject.js[346-353]
src/providers/python_poetry.js[17-42]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`Base_pyproject._createSbom()` now calls `_getDependencyData()` with `lockFileDir`, which changes the effective project context for providers that derive dependency data from the working directory (notably `Python_poetry`). This can cause member-manifest analysis to resolve dependencies for the lockfile directory’s project instead of the requested `pyproject.toml`.

## Issue Context
- `Base_pyproject._createSbom()` parses the requested manifest, but passes `lockFileDir` into `_getDependencyData()`.
- `Python_poetry._getDependencyData()` ignores `parsed` and uses `manifestDir` to run `poetry show ...`.

## Fix Focus Areas
- src/providers/base_pyproject.js[346-353]
- src/providers/python_poetry.js[17-42]

## Suggested fix approach
- Change the contract so providers receive both:
 - `projectDir` (directory of the requested manifest)
 - `lockFileDir` (directory where the lock file was found)
- Update `Base_pyproject._createSbom()` to call something like `_getDependencyData({ projectDir: manifestDir, lockFileDir }, parsed, opts)` (or add an extra parameter).
- For `Python_poetry`, ensure commands are executed in `projectDir` (or explicitly point Poetry at the requested project if it supports a directory flag), while still using the correct lockfile location as needed.
- Keep `Python_uv` behavior using `lockFileDir` if that’s required for workspace export, but do so explicitly via the new parameters.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

Python_pip_pyproject identifies the root entry by checking download_info.dir_info and excludes all
dir_info entries from the graph, which can misidentify the root and drop local/path dependencies.
Pip reports already contain a requested flag suitable for reliable root identification, so the
current approach can produce an incorrect dependency tree and wrong direct/transitive
classification.

Code

src/providers/python_pip_pyproject.js[R63-75]

+		let rootEntry = packages.find(p => p.download_info?.dir_info !== undefined)
+		let rootRequires = rootEntry?.metadata?.requires_dist || []
+
+		let directDepNames = new Set()
+		for (let req of rootRequires) {
+			if (this._hasExtraMarker(req)) { continue }
+			let name = this._extractDepName(req)
+			if (name) { directDepNames.add(this._canonicalize(name)) }
+		}
+
+		let graph = new Map()
+		let nonRootPackages = packages.filter(p => p.download_info?.dir_info === undefined)
+

Evidence

The implementation selects the root via packages.find(...dir_info...) and builds the graph only
from packages where dir_info is undefined. The recorded pip report fixture demonstrates that pip
provides an explicit requested boolean for entries, but the implementation does not use it;
relying on dir_info is not unique to the root if local/path dependencies exist.

src/providers/python_pip_pyproject.js[59-99]
test/providers/tst_manifests/pyproject/pip_pep621/pip_report.json[4-13]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`Python_pip_pyproject._parsePipReport()` treats the first `download_info.dir_info` entry as the root and removes all `dir_info` entries from the dependency graph. This can misidentify the root project and omit legitimate local/path dependencies.

## Issue Context
Pip report entries contain a `requested` flag (seen in the repo’s pip report fixture) that can be used to identify the root request more reliably than `dir_info`.

## Fix Focus Areas
- src/providers/python_pip_pyproject.js[59-99]
- test/providers/tst_manifests/pyproject/pip_pep621/pip_report.json[4-13]

## Suggested fix approach
- Identify the root entry using `requested: true` (and/or matching the parsed project name), not `dir_info`.
- Build the graph from all non-root packages, including those with `dir_info` (local/path deps), instead of excluding them wholesale.
- Only exclude the actual root project from the graph, not every `dir_info` entry.
- Add/extend tests with a pip report containing a local/path dependency that also has `dir_info` to ensure it stays in the graph and is correctly classified.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

Base_pyproject only treats a Poetry workspace boundary as present when both [tool.poetry] and
poetry.lock exist, so a Poetry project root without poetry.lock will not stop the upward search.
This can cause lockfile discovery to continue into parent directories and potentially select an
unrelated poetry.lock.

Code

src/providers/base_pyproject.js[R95-97]

+			if (content.tool?.poetry && fs.existsSync(path.join(dir, 'poetry.lock'))) {
+				return true
+			}

Evidence

_findLockFileDir() stops searching when _isWorkspaceRoot() returns true; for Poetry,
_isWorkspaceRoot() currently requires both content.tool?.poetry and an on-disk poetry.lock. In
contrast, the JavaScript workspace boundary logic stops at workspace markers even without a lockfile
present, preventing accidental walk-up into unrelated parent projects.

src/providers/base_pyproject.js[77-101]
src/providers/base_javascript.js[114-143]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`Base_pyproject._isWorkspaceRoot()` only considers a Poetry workspace boundary when `[tool.poetry]` is present *and* `poetry.lock` exists. If a Poetry root is missing its lock file, `_findLockFileDir()` may walk above the project root and accidentally match a parent directory’s lock file.

## Issue Context
Other ecosystems in this repo treat workspace markers as hard boundaries even when the lock file is absent.

## Fix Focus Areas
- src/providers/base_pyproject.js[77-101]

## Suggested fix approach
- Treat the presence of `[tool.poetry]` in `pyproject.toml` as a workspace boundary regardless of whether `poetry.lock` exists.
- Keep the existing uv boundary behavior.
- If you still need the current behavior for some reason, add a guard to prevent escaping beyond the nearest directory containing a `pyproject.toml` with `[tool.poetry]`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

Python_uv parses a member pyproject.toml for editable installs without guarding against TOML parse
failures. A malformed or unreadable member pyproject.toml will throw and abort dependency parsing
for the whole project.

Code

src/providers/python_uv.js[R71-88]

+			if (child.type === 'global_opt') {
+				let optNode = child.children.find(c => c.type === 'option')
+				let pathNode = child.children.find(c => c.type === 'path')
+				if (optNode?.text === '-e' && pathNode && manifestDir) {
+					let memberDir = path.resolve(manifestDir, pathNode.text)
+					let memberManifest = path.join(memberDir, 'pyproject.toml')
+					if (fs.existsSync(memberManifest)) {
+						let memberParsed = parseToml(fs.readFileSync(memberManifest, 'utf-8'))
+						let name = memberParsed.project?.name || memberParsed.tool?.poetry?.name
+						let version = memberParsed.project?.version || memberParsed.tool?.poetry?.version
+						if (name && version) {
+							let key = this._canonicalize(name)
+							currentPkg = { name, version, parents: new Set() }
+							packages.set(key, currentPkg)
+							collectingVia = false
+							continue
+						}
+					}

Evidence

The new editable-install handling reads and parses memberManifest with parseToml(...) without a
try/catch, unlike Base_pyproject’s similar TOML parsing which explicitly catches parse errors. This
makes uv workspace parsing fragile when encountering a bad member manifest.

src/providers/python_uv.js[70-89]
src/providers/base_pyproject.js[90-101]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`Python_uv._parseUvExport()` attempts to parse editable member `pyproject.toml` without error handling. Any TOML parse error will throw and fail the entire analysis.

## Issue Context
`Base_pyproject._isWorkspaceRoot()` already demonstrates the preferred pattern: wrap TOML parsing in a try/catch and treat failures as non-fatal.

## Fix Focus Areas
- src/providers/python_uv.js[70-89]

## Suggested fix approach
- Wrap `parseToml(fs.readFileSync(...))` in a try/catch.
- On failure, fall back to the existing behavior for that node (e.g., set `currentPkg = null` and continue), rather than throwing.
- Consider also guarding `fs.readFileSync` in case of permissions or transient FS issues.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools