rensoai-code-graph 1.1.1

Dependency graph analyzer for code, tests, docs, and policy surfaces. A tiny launcher that downloads + SHA256-verifies the prebuilt code_graph + code_graph-mcp binaries on first run.

rensoai-code-graph (PyPI distribution wrapper)

This package is still published for distribution compatibility, but customer-facing install docs live at https://cg.renso.ai/docs#install and document only the curl/script installer. The PyPI artifacts are per-platform wheels with the prebuilt code_graph and code_graph-mcp binaries bundled.

Files in this directory

• pyproject.toml — Hatch backend, [project.scripts] entries, pinned cibuildwheel matrix
• src/rensoai_code_graph/ — Python package: launcher + console-script entry points
• scripts/build_wheels.py — release-time wheel builder
• README.md — what users see on PyPI

Per-platform wheel matrix

Wheel tag	Binary target
py3-none-manylinux_2_28_x86_64.whl	x86_64-unknown-linux-gnu
py3-none-manylinux_2_28_aarch64.whl	aarch64-unknown-linux-gnu
py3-none-macosx_10_12_x86_64.whl	x86_64-apple-darwin
py3-none-macosx_11_0_arm64.whl	aarch64-apple-darwin
py3-none-win_amd64.whl	x86_64-pc-windows-msvc

Each wheel is py3-none-<platform> so end users only ever pull one wheel per machine, regardless of Python version.

No sdist

pyproject.toml excludes everything from the sdist target. Only wheels go to PyPI — there is no source distribution that could trick a user (or a downstream build system) into compiling from source.

How a release ships wheels

.github/workflows/release.yml job publish-pip:

1. Downloads the prebuilt-binary tarballs from dist/.
2. Runs scripts/build_wheels.py which, per platform:
   • Templates src/rensoai_code_graph/__version__.py with the release version.
   • Copies the matching binary into src/rensoai_code_graph/_binaries/.
   • Runs python -m build --wheel (Hatch backend) targeting the correct platform tag.
3. twine upload ships all wheels to PyPI.