PR Pip CLI

Pip-aware PR and CI triage for Python teams.

PR Pip CLI is planned as a local-first CLI and Python library that turns pip install, dependency resolution, test, lint, typecheck, and build failures into actionable pull request context.

It will focus on evidence already present in a local workspace or CI artifact directory: Python project metadata, requirements files, lock files, virtual environment context, test reports, linter output, type checker diagnostics, package build logs, and pip resolver errors.

It should answer the first production question after a Python PR fails:

Which package, environment, dependency, test, or quality gate failed, what evidence proves it, and how do I reproduce it locally?

Status

Project seed.

This repository is public so the project direction can be shaped openly, but no CLI package has been published yet and no production release is available.

The first implementation should stay small, deterministic, and usable without GitHub tokens, CI API access, AI providers, telemetry, or external services.

Why This Exists

Generic PR tools can show that CI failed. Generic agents can inspect logs when prompted. Larger observability platforms can collect broad build telemetry.

PR Pip CLI will focus on a narrower production workflow:

Turn pip and Python CI failures into deterministic PR context.

This is useful for:

• Python teams maintaining libraries, CLIs, services, or monorepos.
• OSS maintainers triaging failing pull requests.
• Package maintainers validating PyPI publishing readiness.
• Engineering platform teams standardizing Python CI failure summaries.
• Regulated teams that cannot send logs to external services.
• Internal agent platforms that need structured local evidence.

Pip And Python Packaging Focus

The initial direction is pip-first and PyPI-aware, with room to support adjacent Python package managers later.

Expected inputs:

• pyproject.toml.
• requirements.txt, requirements-dev.txt, and similar requirements files.
• constraints files such as constraints.txt.
• dependency lock files when present, including uv.lock, poetry.lock, Pipfile.lock, or generated requirements locks.
• pip install and resolver logs.
• package build logs for wheels and source distributions.
• pytest reports, including JUnit XML.
• coverage reports such as Cobertura XML or coverage.py output.
• Ruff, Flake8, Pylint, or similar linter output.
• mypy, pyright, pyre, or similar type checker diagnostics.
• tox and nox session output.
• virtual environment and Python version metadata when available from CI logs or project config.

Expected output:

• human-readable text for maintainers and contributors;
• stable JSON for CI systems and coding agents;
• package, module, or test-suite mapping;
• failing dependency, resolver, test, lint, typecheck, or build context;
• report path or log artifact references;
• minimal reproduction commands such as python -m pip install -r requirements.txt, python -m pytest, tox -e py, or python -m build when enough evidence exists.

Planned MVP

The first useful version should prioritize:

• discovery of Python project metadata from pyproject.toml;
• detection of requirements and constraints files;
• parsing of pip install and resolver failures from captured logs;
• parsing of pytest JUnit XML reports;
• parsing of Ruff or Flake8-style diagnostics from machine-readable output or captured logs;
• parsing of mypy or pyright diagnostics from captured logs;
• mapping findings back to files, packages, modules, or test cases;
• deterministic text output;
• deterministic JSON output;
• demo fixtures for failing and passing Python projects;
• end-to-end CLI tests;
• GitHub Actions examples without requiring GitHub API access at runtime.

Non-Goals For The First MVP

• Replacing pip, PyPI, Poetry, uv, Conda, Pipenv, tox, or nox.
• Executing arbitrary project commands as part of analysis.
• Requiring hosted CI provider APIs.
• Uploading logs to external services.
• Providing AI-generated explanations as a required runtime feature.
• Supporting every Python package manager on day one.
• Publishing a native GitHub or GitLab API adapter before the local evidence model is stable.

Planned Usage

The exact commands are still subject to design, but the intended shape is:

prpip fails --project .
prpip fails --project . --format json
prpip why --project . --file src/package/module.py

The CLI should inspect existing reports and logs. It should not need network access to answer local failure-context questions.

Package Manager Scope

pip and PyPI are the initial baseline because they are the most universal center of Python package installation and publishing.

Future support can add explicit detection for:

• Poetry;
• uv;
• Conda;
• Pipenv;
• pip-tools;
• PEP 517 and PEP 518 build backends;
• PEP 621 project metadata;
• editable installs and workspace-style monorepos.

The tool should respect the project's chosen source of truth instead of forcing every Python repository into one dependency model.

Relationship To PR Maven CLI

PR Pip CLI follows the same product family idea as PR Maven CLI:

• local-first analysis;
• deterministic evidence;
• text and JSON output;
• CI and agent-friendly summaries;
• no runtime dependency on provider tokens for core analysis.

The implementation and terminology should be native to the Python packaging ecosystem, not a Java/Maven model copied into Python projects.

Contributing

This project is intentionally early.

Good first contribution areas will likely include:

• pip resolver failure fixtures;
• pytest report fixtures;
• linter diagnostic fixtures;
• type checker diagnostic fixtures;
• pyproject.toml and requirements fixtures;
• JSON output contracts;
• CLI ergonomics;
• documentation for CI examples.

Founder

PR Pip CLI was founded by Will-thom.

License

License to be added before the first release.