Platform and artifact support

KGLite’s Python distribution is a native PyO3 extension. Support claims are tiered by evidence: running a test suite is stronger than producing an artifact, and producing an artifact is stronger than a plausible source build. The active workflows and generated project facts are the machine-readable authority.

CPython and wheel policy

Published extension wheels use CPython’s stable ABI with a Python 3.10 floor (cp310-abi3). One platform wheel can therefore serve CPython 3.10 and newer on the same OS/architecture/libc target. Normal installation is:

pip install kglite

The base wheel has no required Python packages. Optional integrations declare their own dependencies: kglite[pandas] for DataFrame workflows, kglite[networkx] for the NetworkX bridge (including pandas), and kglite[neo4j] for the Neo4j driver.

Evidence tiers

Runtime-tested paths

  • Linux x86_64 source builds on CPython 3.10, 3.12, 3.13, and 3.14 run the Python suite.

  • Linux x86_64 CPython 3.14t builds without abi3 and runs the dedicated free-threading concurrency suite. This proves a source-build configuration; a free-threaded wheel is not currently published.

  • A Linux x86_64 CPython 3.12 job builds a wheel, installs its networkx extra into a clean environment outside the checkout, and executes a bridge round-trip.

  • At release time, the macOS arm64 wheel is installed on CPython 3.14 with current pyarrow for the allocator-coexistence canary.

  • Windows x86_64 and macOS arm64 run the Rust engine’s unit suite, which covers the storage backends — including disk mode, whose memory-mapped file lifetimes behave differently on Windows than on POSIX. This is a native-engine test, not a Python-level one: the Python API surface on Windows remains build-verified rather than runtime-tested.

Release-blocking wheel builds

These artifacts must build before publication can proceed:

Target

Compatibility floor

x86_64-pc-windows-msvc

64-bit Windows

aarch64-apple-darwin

macOS 11+ arm64

x86_64-apple-darwin

macOS 11+ x86_64

x86_64-unknown-linux-gnu

manylinux2014 / glibc 2.17+

x86_64-unknown-linux-musl

musllinux 1.2+

A release-blocking build is not the same as a full runtime test on that target. Windows and cross-built macOS x86_64 artifacts are build-verified unless a separate smoke job is listed above.

Best-effort wheel builds

Linux aarch64 artifacts are published when their cross-build succeeds, but the job is explicitly non-blocking:

Target

Compatibility floor

aarch64-unknown-linux-gnu

manylinux 2.28 / glibc 2.28+

aarch64-unknown-linux-musl

musllinux 1.2+

Do not plan a deployment around a best-effort wheel without checking that the desired release actually contains it.

PyPy

PyPy is not a supported published-artifact target. The released macOS wheel, for example, is tagged cp310-abi3-macosx_11_0_arm64; a probe with PyPy 3.10 rejects it because PyPy requires a pp310-compatible artifact. The project therefore does not publish the PyPy classifier. A future PyPy claim requires a dedicated build and runtime test, not only a source-level PyO3 capability.

Wheel-first distribution, with a tested source fallback

PyPI publication uploads platform wheels for the targets listed above, and a source distribution for everything else. When pip finds no matching wheel it falls back to the sdist and builds from source, which requires a Rust toolchain on the installing machine.

The sdist is not a courtesy upload: every release builds it, unpacks it into an empty directory to confirm it resolves with no sibling checkouts present, then pip installs the tarball and imports the result. A source fallback that cannot build is worse than none — it turns a clear “no matching distribution” into a compile error deep in someone else’s install log.

What this does not promise is that an unlisted platform is release-tested. The sdist is verified to build on the CI runner; it is not exercised on every target it might reach. Wheels remain the supported path, and a platform in the table above has been built and smoke-tested there.

Developers can also work from a source checkout with a Rust toolchain:

git clone https://github.com/kkollsga/kglite.git
cd kglite
python -m venv .venv
source .venv/bin/activate
pip install maturin
maturin develop --release

That is a source-build route, not a promise that an unlisted platform is release-tested. Rust-only consumers should depend on the kglite crate and do not need the Python extension.

Bundled entry points

The same wheel installs both kglite and kglite-mcp-server. Each console script is a thin Python shim over its bundled Rust library inside the extension, sharing one graph engine. There is no second CLI/server wheel dependency; the standalone kglite-cli distribution is an alternative for CLI-only users.