45d800bacd
Add a hatchling build backend, a `conandeps` console script and a uv.lock so `uv tool install .` (or from a git URL) yields a `conandeps` command in an isolated venv. Add PEP 723 inline metadata to conandeps.py so the single file also works standalone via `uv run conandeps.py`. Pin requires-python to <3.12: Conan 1.x imports the removed `imp` module (the Containerfile comment wrongly blamed distutils). Add uv to the dev image so both install paths are verified inside the container. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EYNdaGDrpaqDyT8QtrTQbM
74 lines
2.8 KiB
Markdown
74 lines
2.8 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.
|
||
|
||
### Installing with uv
|
||
|
||
```
|
||
uv tool install git+https://<your-forge>/conan-utils # or: uv tool install . from a checkout
|
||
conandeps path/to/conanfile.py -r knor
|
||
```
|
||
|
||
This puts a `conandeps` command on your PATH in its own virtualenv with
|
||
Conan 1.66 — it does not touch or depend on the Conan you use for builds
|
||
(but it does read the same `~/.conan` config, profiles and remotes).
|
||
|
||
The script also carries PEP 723 inline metadata, so the single file works on
|
||
its own without a checkout:
|
||
|
||
```
|
||
uv run conandeps.py path/to/conanfile.py -r knor
|
||
```
|
||
|
||
Python 3.8–3.11 is required; Conan 1.x does not run on 3.12+.
|
||
|
||
### Usage
|
||
|
||
```
|
||
./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`.
|