import { Tabs, TabItem, Aside } from "@astrojs/starlight/components";

codeanalyzer-python is published on PyPI and installs with any Python package manager. It also ships a one-line installer and a Homebrew formula.

The formula depends on [uv](https://docs.astral.sh/uv/) and installs `canpy` as an isolated, version-pinned uv tool — the package and its dependencies are resolved and cached on first run.

```shell
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/codellm-devkit/codeanalyzer-python/releases/latest/download/canpy-installer.sh | sh
```

This installs the canpy command. Verify it:

canpy --help

canpy can emit a Neo4j property graph instead of analysis.json. The graph.cypher snapshot (--emit neo4j with no --neo4j-uri) and the schema contract (--emit schema) need nothing extra. Only the incremental live Bolt push (--emit neo4j --neo4j-uri …) needs the Neo4j driver, which ships as an optional extra:

pip install 'codeanalyzer-python[neo4j]'

This pulls in neo4j>=5,<6. The driver is imported lazily off the default path, so a standard install stays lean; if you reach for --neo4j-uri without the extra, canpy raises a clear error telling you to install it.

# graph.cypher snapshot — no extra deps; load it later with cypher-shell
canpy --input ./my-service --emit neo4j --app-name my-service --output ./out

# live incremental push — needs the [neo4j] extra
export NEO4J_PASSWORD=…   # keep it out of shell history / the process list
canpy --input ./my-service --emit neo4j --app-name my-service \
  --neo4j-uri bolt://localhost:7687 --neo4j-user neo4j

The password (and the URI, user, and database) are read from the standard NEO4J_PASSWORD / NEO4J_URI / NEO4J_USERNAME / NEO4J_DATABASE environment variables when the matching flag is omitted, so credentials need not appear on the command line. See the Neo4j graph guide for the producer/consumer model and the CLDK read-back SDK.

• Python 3.10 or newer.

To analyze a project the way it actually runs, canpy builds an isolated virtual environment for it (under .codeanalyzer/), installs the project's dependencies into it, and resolves symbols against that environment. That means the host needs venv support and a compiler toolchain for any dependencies with native extensions.

On older releases:

```shell
sudo yum groupinstall "Development Tools"
sudo yum install python3-pip python3-venv python3-devel
```

# Homebrew Python (recommended)
brew install python@3.12
```

Using pyenv instead:

```shell
pyenv install 3.12.0   # or any 3.10+ release
pyenv global 3.12.0    # or `pyenv local 3.12.0` per project
```

export SYSTEM_PYTHON=/usr/bin/python3

In CI, containers, or sandboxed runs where you'd rather not provision a per-project environment, pass --no-venv. canpy then resolves imports against the ambient Python interpreter instead of building one under .codeanalyzer/:

canpy --input ./my-service --no-venv

This trades some resolution fidelity for speed and a smaller footprint — it's most useful when the project's dependencies are already importable in the current environment (for example, inside an image that already has them installed).

CodeQL-based call-graph augmentation is opt-in via --codeql. You do not need to install CodeQL yourself — on first use canpy downloads the CLI into the project cache (<cache-dir>/codeql/) and reuses it. If a codeql binary is already on your PATH, the project-local copy still takes precedence for deterministic behavior. See CodeQL analysis.

The project uses uv for development.

git clone https://github.com/codellm-devkit/codeanalyzer-python
cd codeanalyzer-python
uv sync --all-groups          # installs runtime + test + dev dependencies
uv run canpy --input /path/to/python/project

Run the test suite with:

uv run pytest --pspec -s