v1.14.0

Release v1.14.0

Highlights

Serve a Tesseract in its own process with Tesseract.from_source

Tesseract.from_source serves a tesseract_api.py via tesseract-runtime serve in a dedicated subprocess, with no container and no tesseract build step. Unlike from_tesseract_api, the Tesseract gets its own interpreter, global state and signal handlers, so it is safe for cases where sharing them breaks (e.g. nesting JAX inside JAX) and can depend on packages that conflict with the caller's environment.

from tesseract_core import Tesseract

with Tesseract.from_source("path/to/tesseract_api.py") as t:
result = t.apply({"a": 1})

By default, the Tesseract's environment is built from its tesseract_config.yaml and requirements file into a .tesseract-venv directory next to tesseract_api.py. It is reused on later calls and rebuilt when the requirements change. This needs uv (or conda for requirements.provider: conda). To use an existing environment instead, pass python_executable=... (e.g. sys.executable). That interpreter must have tesseract-core[runtime] and the Tesseract's requirements installed.

Things to know:

• from_source must be used as a context manager (or served explicitly), since there is a process to clean up.
• It is not a sandbox: the child inherits the caller's environment variables, working directory, filesystem access and user.
• Scratch directories for input_path / output_path are created and cleaned up for you if you don't pass them. Because client and server are ordinary processes on the same host, json+binref and experimental_binref_pool work without bind mounts, including on macOS. See the fast same-machine runs guide.

Install dependencies from a PEP 751 lockfile

uv-pip builds can now install from a PEP 751 pylock.toml instead of a flat requirements file. The lockfile pins exact versions, indexes and hashes, so builds do no dependency resolution and install the same wheels every time:

build_config:
requirements:
provider: uv-pip
requirements_file: pylock.toml

The format is inferred from the filename (pylock.toml or pylock.*.toml). requirements_file must be a bare filename in the Tesseract directory. It defaults to tesseract_requirements.txt, so existing Tesseracts are unaffected. Lockfiles that use private indexes authenticate through the existing host_credentials / --secret mechanism. See examples/pylock for a two-index example, including a script that exports a lockfile from uv.lock.

Other changes

• /abstract_eval now reports the schema's declared dtype. Inputs are coerced to the InputSchema dtype, as apply already did. Before, a float64 aval passed to a Float32 field came back as float64 from abstract_eval and float32 from apply. Both now return float32. If you relied on abstract_eval echoing the caller's dtype, expect the declared dtype instead.
• tesseract-runtime serve now applies the configured compression. Before, --compression lz4 / TESSERACT_RUNTIME_COMPRESSION=lz4 only took effect in tesseract-runtime apply. Clients can also pick compression per request via the Accept header (e.g. Accept: application/json+base64; compression=lz4, or compression=none to disable it).
• Hardened json+binref decoding. The client now refuses buffer references that resolve outside output_path, including via absolute paths, .. traversal and symlinks. output_path is now required to decode a json+binref response. Previously the client silently fell back to the current working directory.
• JAX arrays work with gpu_transport="cuda_ipc". GPU arrays that expose only DLPack (such as JAX's) are now exported by reference. Before, they were silently copied to the host.
• Plain integers are now accepted for unsigned integer fields (e.g. UInt8). Out-of-range values are still rejected.
• Multiple from_tesseract_api instances in one process no longer share runtime config overrides (e.g. output_path, output_format).
• tesseract list --format json prints machine-readable output with full image IDs.
• LocalClient.api_module exposes the Python module that a from_tesseract_api Tesseract wraps.
• TesseractReference fields are now identifiable in the OpenAPI schema by the title TesseractReference and x-tesseract-type: reference.
• Tesseract objects now expose a supported_gpu_transports attribute that can be used to find out which GPU transports a Tesseract object was configured with.

What's Changed

Features

• Add Tesseract.from_source to serve a Tesseract a separate subprocess without a container (#669)
• Install dependencies from a PEP 751 lockfile (#767)
• Machine readable output flag for tesseract list (#780)
• Expose LocalClient.api_module (#785)
• (sdk) Build environments for from_source automatically (#762)
• (sdk) Expose Tesseract.supported_device_transports (#793)

Bug Fixes

• (runtime) Let a signed integer reach an unsigned field (#769)
• Reset runtime config before each in-process Tesseract instance (#703)
• Coerce abstract_eval input avals to the schema dtype (#772)
• Confine json+binref buffer references to output_path (#783)
• (runtime) Identify TesseractReference port in OpenAPI schema (#777)
• Accept DLPack CUDA arrays (e.g. JAX) in GPU transports (#781)
• (runtime) Apply configured compression in serve endpoints (#789)

Refactor

• (sdk) Make deprecation tombstones time-based (#764)

Documentation

• Fix broken 'Learn more' links in README (#774)

Full diff: v1.13.0...v1.14.0