• Fixed requirements.txt parser initialization by removing custom locateFile configuration
• Re-enabled previously commented-out Python pip provider tests
• Restored test coverage for isSupported, stack analysis, and virtual environment scenarios

Simplify parser initialization configuration

• Removed custom locateFile() configuration from Parser.init() call
• Simplified initialization to use default web-tree-sitter WASM loading
• Maintains Language.load() for tree-sitter-requirements WASM

src/providers/requirements_parser.js

Re-enable all Python pip provider tests

• Uncommented isSupported test suite for requirements.txt file detection
• Re-enabled stack analysis tests using pipdeptree utility
• Restored component analysis tests with pipdeptree utility
• Uncommented virtual environment test suite with multiple scenarios

test/providers/python_pip.test.js

Description

The re-enabled pipdeptree tests invoke async helpers without returning/awaiting their Promises, so
Mocha will finish the test before assertions run, producing false positives or unhandled rejections.

Code

test/providers/python_pip.test.js[R75-83]

+		test(`verify requirements.txt sbom provided for stack analysis using pipdeptree utility with scenario ${scenario}`, () => {
+			sharedStackAnalysisTestFlow(testCase, true);
+			// these test cases takes ~2500-2700 ms each pr >10000 in CI (for the first test-case)
+		}).timeout(process.env.GITHUB_ACTIONS ? 30000 : 10000)

-		// test(`verify requirements.txt sbom provided for component analysis using pipdeptree utility with scenario ${scenario}`, () => {
-		// 	sharedComponentAnalysisTestFlow(testCase, true);
-		// 	// these test cases takes ~1400-2000 ms each pr >10000 in CI (for the first test-case)
-		// }).timeout(process.env.GITHUB_ACTIONS ? 15000 : 10000)
+		test(`verify requirements.txt sbom provided for component analysis using pipdeptree utility with scenario ${scenario}`, () => {
+			sharedComponentAnalysisTestFlow(testCase, true);
+			// these test cases takes ~1400-2000 ms each pr >10000 in CI (for the first test-case)
+		}).timeout(process.env.GITHUB_ACTIONS ? 15000 : 10000)

Evidence

The pipdeptree test callbacks are synchronous but call async helpers; those helpers await provider
calls and contain assertions, which will execute after the test has already ended.

test/providers/python_pip.test.js[75-83]
test/providers/python_pip.test.js[11-24]
test/providers/python_pip.test.js[26-48]

Agent prompt

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

### Issue description
The pipdeptree tests are declared with synchronous callbacks but call `sharedStackAnalysisTestFlow` / `sharedComponentAnalysisTestFlow`, which are `async` and contain awaited provider calls + assertions. Mocha will mark these tests as complete immediately, causing false positives and/or unhandled promise rejections.

### Issue Context
This was introduced by uncommenting the pipdeptree test blocks.

### Fix Focus Areas
- test/providers/python_pip.test.js[75-83]

### Implementation sketch
- Change both tests to `async () => { await shared... }`.
 - Alternatively: `return sharedStackAnalysisTestFlow(...)` / `return sharedComponentAnalysisTestFlow(...)`.

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

Description

The re-enabled pipdeptree tests pass a boolean true into opts.TRUSTIFY_DA_PIP_USE_DEP_TREE, but
option parsing only accepts string values, so the controller always uses the default "false" and
never executes the pipdeptree code path.

Code

test/providers/python_pip.test.js[R75-82]

+		test(`verify requirements.txt sbom provided for stack analysis using pipdeptree utility with scenario ${scenario}`, () => {
+			sharedStackAnalysisTestFlow(testCase, true);
+			// these test cases takes ~2500-2700 ms each pr >10000 in CI (for the first test-case)
+		}).timeout(process.env.GITHUB_ACTIONS ? 30000 : 10000)

-		// test(`verify requirements.txt sbom provided for component analysis using pipdeptree utility with scenario ${scenario}`, () => {
-		// 	sharedComponentAnalysisTestFlow(testCase, true);
-		// 	// these test cases takes ~1400-2000 ms each pr >10000 in CI (for the first test-case)
-		// }).timeout(process.env.GITHUB_ACTIONS ? 15000 : 10000)
+		test(`verify requirements.txt sbom provided for component analysis using pipdeptree utility with scenario ${scenario}`, () => {
+			sharedComponentAnalysisTestFlow(testCase, true);
+			// these test cases takes ~1400-2000 ms each pr >10000 in CI (for the first test-case)

Evidence

The tests pass true (boolean) for the flag; getCustom() ignores non-string values in opts, and
python_controller compares the resulting value against the string "true", so the pipdeptree branch
can’t be reached via these tests.

test/providers/python_pip.test.js[75-82]
test/providers/python_pip.test.js[11-18]
test/providers/python_pip.test.js[26-39]
src/tools.js[37-42]
src/providers/python_controller.js[189-202]

Agent prompt

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

### Issue description
`TRUSTIFY_DA_PIP_USE_DEP_TREE` is passed as a boolean in test opts, but `getCustom()` only reads string values from `opts`. As a result, pipdeptree tests never enable the pipdeptree path.

### Issue Context
The provider uses string comparisons (`!== "true"`), so the flag must be a string when passed via `opts`.

### Fix Focus Areas
- test/providers/python_pip.test.js[11-18]
- test/providers/python_pip.test.js[26-39]
- test/providers/python_pip.test.js[75-82]

### Implementation sketch
- In both shared flows, set:
 - `const opts = { TRUSTIFY_DA_PIP_USE_DEP_TREE: usePipDepTreeUtility ? "true" : "false" }`
- Keep the call sites as-is (passing boolean) or also convert call sites to pass strings for clarity.

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

Description

The re-enabled virtual-environment tests set process.env.TRUSTIFY_DA_PYTHON_VIRTUAL_ENV = "true"
and never restore it, making subsequent tests/order run with an unintended virtualenv behavior.

Code

test/providers/python_pip.test.js[R95-101]

+			// load the expected sbom stack analysis
+			let expectedSbom = fs.readFileSync(`test/providers/tst_manifests/pip/${testCase}/expected_stack_sbom.json`,).toString()
+			process.env["TRUSTIFY_DA_PYTHON_VIRTUAL_ENV"] = "true"
+			// process.env["TRUSTIFY_DA_DEBUG"] = "true"
+			expectedSbom = JSON.stringify(JSON.parse(expectedSbom), null, 4)
+			// invoke sut stack analysis for scenario manifest
+			let providedDataForStack = await pythonPip.provideStack(`test/providers/tst_manifests/pip/${testCase}/requirements.txt`)

Evidence

The test mutates a global environment variable; the provider reads that variable to decide whether
to create a virtual environment, and the suite’s teardown only restores fake timers, not the env
var.

test/providers/python_pip.test.js[95-99]
test/providers/python_pip.test.js[117-117]
src/providers/python_pip.js[158-163]

Agent prompt

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

### Issue description
The virtualenv test suite sets `process.env.TRUSTIFY_DA_PYTHON_VIRTUAL_ENV` to "true" but never restores it. This leaks global state into other tests and makes the test run order-dependent.

### Issue Context
`python_pip` reads `TRUSTIFY_DA_PYTHON_VIRTUAL_ENV` via `getCustom(...)`, so the setting can be provided through `opts` instead of `process.env`.

### Fix Focus Areas
- test/providers/python_pip.test.js[94-115]
- src/providers/python_pip.js[158-163]

### Implementation sketch
Option A (preferred):
- Remove the `process.env[...] = "true"` line.
- Call `pythonPip.provideStack(..., { TRUSTIFY_DA_PYTHON_VIRTUAL_ENV: "true" })`.

Option B:
- Capture previous value before setting, and restore it in `afterEach`/`afterAll` (including deleting the key if it was previously unset).

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