- Python 96.5%
- Shell 1.8%
- Dockerfile 1.7%
conandeps.py lists direct and indirect dependencies of a conanfile.py, checks whether Release/Debug/RelWithDebInfo binaries exist on a remote for the exact profile, and reports explicit (override=True) and implicit requirement overrides both as a list and on the edges of the dependency tree. Text output by default, optional self-contained HTML via --html. The graph is built once per build type through Conan's own info API and each node's binary status is read back, so package_id modes and options are honoured like a real install. Overrides are parsed from Conan's WARN output since 1.x does not record them on the graph. Development runs inside a pinned podman container (Containerfile, dev.sh) with Conan 1.66 on Python 3.11. Tests start a throw-away conan_server and verify missing-binary and override detection end to end. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EYNdaGDrpaqDyT8QtrTQbM |
||
|---|---|---|
| tests | ||
| .gitignore | ||
| conandeps.py | ||
| Containerfile | ||
| dev.sh | ||
| pyproject.toml | ||
| README.md | ||
conan-utils
Small utilities for Conan 1.x (targets 1.66). All development happens inside a pinned Podman container so nothing from the host environment leaks in.
conandeps.py
Given a conanfile.py, conandeps reports:
- direct and indirect dependencies (host and build context),
- whether a binary exists on the remote for Release, Debug and RelWithDebInfo (configurable) for your exact profile,
- every requirement override – explicit
override=Trueand implicit ones (a downstream consumer asking for a newer version than a transitive dependency declared) – shown both as a list and on the edges of the dependency tree.
./conandeps.py path/to/conanfile.py -r knor # text report
./conandeps.py path/to/conanfile.py -r knor -pr myprofile # explicit profile
./conandeps.py path/to/conanfile.py -r knor --html report.html
./conandeps.py path/to/conanfile.py -r knor --build-types Release,Debug
Options mirror conan info: -pr/--profile, -s/--settings, -o/--options
(all repeatable) and -u/--update. Exit status is 1 when any binary is
missing, so it can gate a CI job.
How it works
Rather than matching conan search output by hand, the dependency graph is
built once per build type through Conan's own info code path and each node's
binary status (Cache/Download/Missing, …) is read back. That means
package_id() customisations, options and default_package_id_mode are
honoured exactly as a real conan install would.
Conan 1.x does not keep override information on the graph – the only trace is a
WARN: … requirement A overridden by B to C line. The tool captures Conan's
output while building the graph and parses those lines.
Development
./dev.sh build # build the conan-utils-dev image (Conan 1.66, Python 3.11)
./dev.sh python -m pytest # run the tests
./dev.sh ruff check . && ./dev.sh ruff format .
./dev.sh # interactive shell
The tests start a throw-away conan_server inside the container, upload a
small graph with deliberately missing binaries and overrides, and run the tool
against it with an isolated CONAN_USER_HOME.