olemd/conan-1.6-utilities
1
0
Fork 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions

Add conandeps: dependency, binary-availability and override report for Conan 1.66

Browse source 
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
This commit is contained in:
Ole-Morten Duesund 2026-08-25 14:48:28 +02:00
commit a11e9fb34e
7 changed files with 904 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

52
README.md Normal file
View file

@ -0,0 +1,52 @@
# 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`.