a11e9fb34e
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
52 lines
2.1 KiB
Markdown
52 lines
2.1 KiB
Markdown
# 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`.
|