olemd/conan-1.6-utilities
1
0
Fork 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions
conan-1.6-utilities/README.md
Ole-Morten Duesund a11e9fb34e Add conandeps: dependency, binary-availability and override report for Conan 1.66 
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
2026-08-25 14:48:28 +02:00

2.1 KiB
Raw Blame History

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=True and 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.