dcc-mcp-cli

# dcc-mcp-cli-bin — PyPI wrapper for the `dcc-mcp-cli` binary This directory builds the `dcc-mcp-cli` PyPI project: one platform-specific wheel per release that puts the Rust CLI on `PATH`. ```bash # Run it without installing anything uvx dcc-mcp-cli --version # Or install it into a tool environment / venv uv tool install dcc-mcp-cli pip install dcc-mcp-cli ``` ## Why a wrapper instead of a raw binary wheel? `pkg/dcc-mcp-server-bin` ships its raw executable through maturin's `bindings = "bin"`. `dcc-mcp-cli` deliberately does not: | | Raw binary wheel | This wrapper | |---|---|---| | Per-release PyPI storage | ~165 MB (three platforms) | ~66 MB (three platforms) | | PyPI 10 GB budget | ~60 releases | ~152 releases | | Payload | the executable | the release zip, unpacked on first use | The wheel embeds the same `dcc-mcp-cli-<version>-<platform>.zip` the GitHub Release publishes, verifies its SHA-256 against `payload.json`, and unpacks it into the environment's scripts directory on the first invocation. ## Layout ``` pkg/dcc-mcp-cli-bin/ ├── pyproject.toml # hatchling; console script dcc-mcp-cli ├── python/dcc_mcp_cli/ │ ├── __init__.py # public API: binary_path(), main() │ ├── __main__.py # python -m dcc_mcp_cli │ ├── _bootstrap.py # unpack + exec │ └── _payload/ # staged at build time, git-ignored │ ├── payload.json │ └── dcc-mcp-cli-<version>-<platform>.zip └── tests/test_cli_bootstrap.py ``` ## Where the binary lands, and why it matters The bootstrap unpacks the executable into the scripts directory of the interpreter that installed the wheel — `<venv>/bin` on POSIX, `<venv>\Scripts` on Windows — and then executes it. Consequences: - **Component contract.** `current_exe.parent()` resolves to that directory, so `dcc-mcp-cli components ensure dcc-cua` installs `dcc-cua` as a sibling and detects it on the next run. A package manager must therefore keep the…