Migrating 0.13 → 0.14¶

kglite 0.14 focuses the package on the graph engine: the code-graph builder and the dataset loaders moved to standalone projects. Everything else — the engine, Cypher, the fluent API, the MCP server’s graph tools, .kgl files — is unchanged, and every .kgl you saved keeps loading.

If anything broke: the two-line escape¶

pip install "kglite<0.14"

0.13.4 stays on PyPI permanently. Pin, keep working, migrate when ready.

What moved where¶

You used	It became
`kglite.code_tree.build(...)` / `kglite.build_code_tree(...)` / `repo_tree(...)`	The codingest project: `pip install codingest`, then `import codingest` — `codingest.build(".")` returns a `kglite.KnowledgeGraph` and `codingest.repo_tree("owner/name")` clones + builds. (codingest requires kglite ≥ 0.14.)
`kglite code-tree build/status` (CLI)	The `codingest` CLI (`cargo install codingest-cli`): `codingest build .` / `codingest status .`, then `kglite.load(...)` the `.kgl`.
MCP workspace code-graph building (`set_root_dir`, `repo_management`)	Run codingest-mcp instead of `kglite-mcp-server` — see MCP operators: swap the server binary below. `kglite-mcp-server` still serves any existing `.kgl`.
`kglite.datasets.sec` / `.sodir` / `.wikidata`	`pip install kglite-datasets`, then `import kglite_datasets` — a verified drop-in (byte-identical outputs; only the import root changes).
`kglite::api::code_tree` / `kglite::api::datasets` (Rust)	The `codingest` / `kglite-datasets` crates. Read-side code-entity helpers stayed, at `kglite::api::code_entities`.
`kglite_datasets_*` C-ABI functions	Removed from `kglite-c`; pin `kglite-c` 0.13.x, or ask on the tracker if you need them exposed from kglite-datasets.

MCP operators: swap the server binary¶

If your MCP server builds code graphs from source (workspace mode — set_root_dir, repo_management, watch-mode rebuild), swap the binary from kglite-mcp-server to codingest-mcp. codingest-mcp embeds the same kglite-mcp-server tool surface and injects the code-graph builder, so every graph tool — and your <basename>_mcp.yaml manifest — behaves identically. Only the command changes:

{
  "mcpServers": {
    "code-graph": {
      "command": "codingest-mcp",
      "args": ["--root-dir", "/path/to/repo"]
    }
  }
}

The old config read "command": "kglite-mcp-server"; the tools, the manifest, and the same source root are unchanged.

Install it: cargo install codingest-mcp, or grab a prebuilt binary from github.com/kkollsga/codingest/releases.
Rollback: keep the old kglite-mcp-server binary on disk (or pip install "kglite<0.14") and point command back at it.
Just serving an existing .kgl? Nothing to do. kglite-mcp-server --graph path/to/graph.kgl still serves any graph — including codingest-built ones — with every read-side tool. The swap is only needed when the server must build a graph from source.

What did NOT change¶

.kgl files load across the boundary in both directions — graphs built by codingest/kglite-datasets are ordinary kglite graphs.
Code-graph reading: graph.source(), graph.find(), graph.context(), the read_code_source/explore MCP tools, and the rev_diff/affected_tests/dead_code procedures all work on codingest-built graphs.
load_rdf, OKF ingestion, graphgen, blueprints — all still built in.

Why¶

The wheel dropped from 40.3 MB to 18.0 MB, the engine now links zero network code (the entire HTTP/TLS closure left with the loaders), and the builder/loader projects can release on their own cadence. Extraction fidelity is enforced by frozen golden digests captured while both copies were verified byte-identical.