Problem
Opcore detects Python project files and virtualenv/cache paths, but the Python validation adapter currently probes fixed command names from PATH (mypy, pyright, ruff, pytest) and runs no project-aware resolution.
Full Python support needs one canonical resolver for the validation execution context: repo root, package root, pyproject/config files, virtualenv command paths, and fallback behavior.
Evidence
packages/validation-python/src/toolchain.ts probes fixed commands directly through runTool(command, args, { env }).
PythonValidationToolchainOptions accepts only env and pythonCommand.
- The type checker issue is blocked on knowing which checker/config/root to use.
- Opcore init/status already has Python project discovery concepts, but validation does not consume a shared resolver.
Implementation Plan
- Add a Python validation resolver that derives execution context from the repo/workspace, not just global PATH.
- Resolve candidate tools from active env, repo-local
.venv/venv/env, npm/node wrappers where applicable, and PATH in a deterministic order.
- Detect config files such as
pyproject.toml, mypy.ini, setup.cfg, tox.ini, and pyrightconfig.json only for selecting cwd/config args; do not install dependencies.
- Return a typed resolution object used by
python.types, future ruff-backed checks, and adapter status.
- Report missing or conflicting toolchains as explicit degraded/unsupported status with actionable evidence.
Acceptance Criteria
- Tests cover PATH-only, repo-local
.venv/bin, missing-tool, and config-file scenarios without depending on the developer machine.
python.types can consume the resolver instead of probing fixed command names directly.
- Adapter status reports the resolved command/cwd/config source for available tools.
- Missing tools remain honest degraded/unsupported results, never false passes.
npm run test -- tests/validation-python.test.mjs tests/opcore-facade.test.mjs passes.
bash ./scripts/ci/run-local-ci-equivalent.sh passes.
Problem
Opcore detects Python project files and virtualenv/cache paths, but the Python validation adapter currently probes fixed command names from PATH (
mypy,pyright,ruff,pytest) and runs no project-aware resolution.Full Python support needs one canonical resolver for the validation execution context: repo root, package root, pyproject/config files, virtualenv command paths, and fallback behavior.
Evidence
packages/validation-python/src/toolchain.tsprobes fixed commands directly throughrunTool(command, args, { env }).PythonValidationToolchainOptionsaccepts onlyenvandpythonCommand.Implementation Plan
.venv/venv/env, npm/node wrappers where applicable, and PATH in a deterministic order.pyproject.toml,mypy.ini,setup.cfg,tox.ini, andpyrightconfig.jsononly for selecting cwd/config args; do not install dependencies.python.types, future ruff-backed checks, and adapter status.Acceptance Criteria
.venv/bin, missing-tool, and config-file scenarios without depending on the developer machine.python.typescan consume the resolver instead of probing fixed command names directly.npm run test -- tests/validation-python.test.mjs tests/opcore-facade.test.mjspasses.bash ./scripts/ci/run-local-ci-equivalent.shpasses.