v1.2.2

build: vendor a relocatable, re-signed macOS OpenVINO runtime

The pinned openvino==2026.4.1 macos-arm64 pip wheel ships libtbbbind
recording its hwloc dependency as the absolute build-machine path
/usr/local/lib/libhwloc.15.dylib, and gives these dylibs code signatures
that Apple's tools refuse to edit or replace ("link edit information does
not fill the __LINKEDIT segment" from install_name_tool; "internal error
in Code Signing subsystem" from codesign, even for --remove-signature:
the signature region ends 16 bytes short of EOF, which the tools treat as
malformed).

Repair without cctools: parse the thin 64-bit Mach-O load commands and
overwrite the NUL-terminated dylib name strings in place. Replacements
must not outgrow the originals, so every command size and offset stays
byte-identical. Each patched file is then stripped byte-wise in Rust
(delete the LC_CODE_SIGNATURE load command, truncate at the old signature start, shrink
__LINKEDIT to match) and signed ad-hoc fresh (fatal on failure): arm64
refuses to load stale-signed dylibs, and the wheel must be
self-contained. The otool-based verifier is the post-condition proof and
now also rejects an absolute own install name; the Mach-O rewriter and
stripper are unit-tested with synthetic fixtures.

CI: pushes to main are a smoke gate (tests + version-check only); the
full wheel matrix runs on PRs, manual dispatch, and tag pushes. Drop a
stale README maintainer line.

models

models

v1.2.1

feat: one runtime per wheel (1.2.1)

- ort is optional behind the default ort-backend feature; the OpenVINO wheel builds --no-default-features and no longer links ONNX Runtime (pyd 25.5 MB -> 4 MB on Windows)

- backend defaults to the wheel's compiled runtime; requesting the missing backend errors clearly; __backends__ / __runtime_build__ report what is compiled

- OV wheel CI runs the suite on OV (41 passed); ORT-only tests skip via __backends__, and CI asserts __backends__ == ['ov']

- ci: bump actions to Node 24 majors (checkout v6, setup-python v6, upload-artifact v6, download-artifact v7, action-gh-release v3)

v1.2.0

fix: don't require numpy for bytes OCR (panicked on bare installs)

extract_input probed for an ndarray before checking the object type, and pyo3-numpy panics while fetching the numpy C API capsule when numpy is absent, so ocr(bytes) crashed on a bare install. Probe arrays only when numpy is importable (cached per process), and make return_array=True raise a clean RuntimeError instead of panicking. Regression test runs the no-numpy scenario in a subprocess.

Found by the tag-only ov-download-check job: its bare wheel install has no numpy and the byte-input smoke OCR panicked.

v1.1.2

chore: bump to v1.1.2

v1.1.1

Release v1.1.1: attach prebuilt wheels to GitHub release

v1.1.0

fix