APIZIT Linking 0.4.0

Version 0.4.0 turned the compiler-to-runtime handoff into an explicit, fail-closed contract and gave external adapters a supported integration path that does not vendor engine source.

Publication status: 0.4.0 is available from PyPI. PyPI distributions are canonical; this examples repository does not mirror them as a GitHub Release.

Install and verify#

Terminal

python -m pip install "apizit-linking[preview]==0.4.0"
python -m pip show apizit-linking
apizit-linking validate .

Release highlights#

Closed runtime artifact v1#

Compiler output consumed by an adapter is no longer an anonymous list of routes. The closed envelope requires format, version, engine_version, manifest_version, and routes. Unknown or malformed fields are rejected so a deployment never guesses how to execute an artifact.

Strict callable drift detection#

Each compiled route records ordered parameter names, parameter kinds, required and default state, annotations, callable_kind, and return_annotation. The runtime compares every recorded dimension with the imported function before the application starts. Renaming, reordering, adding, removing, or re-annotating a parameter therefore requires recompilation.

Generators fail closed#

Synchronous and asynchronous generators are rejected during compilation and checked again when loading an artifact. Streaming needs a separate lifecycle, cancellation, media-type, and error contract; 0.4.0 does not infer one.

Public canonical manifest schema#

Manifest version: 1 has a closed Draft 2020-12 JSON Schema. Editor validation and apizit-linking validate complement one another: the schema checks the authoring shape, while the compiler resolves functions and verifies semantic bindings.

Supported non-vendored adapter API#

APIZIT and other deployment systems can pin the PyPI package, call compile_linking_file, serialize CompilationResult.to_runtime_dict(), and later create the HTTP application with create_app_from_runtime_artifact. The adapter treats the artifact as opaque and no longer copies private engine modules.

Compatibility consequences#

• Manifest version 1 remains independent from package version 0.4.0.
• Runtime artifact format version 1 describes the serialized shape.
• engine_version must match exactly, even while artifact version remains 1.
• Every engine upgrade requires a fresh compilation; generated artifacts are never edited by hand.
• The old create_app_from_runtime_routes entry point is only a migration bridge for unversioned route lists.

Read the complete compatibility policy before building an external adapter.

Migration and deployment action#

Projects moving from 0.3 should follow the 0.3-to-0.4 guide. APIZIT must pin the released package, compile the manifest during its build, record the engine version and artifact hash, and package the artifact with the exact same runtime dependency. Existing ZIP or image outputs must be rebuilt.

Known boundaries#

Version 0.4.0 does not make preview a production server or sandbox. That historical release did not support declarative custom status codes, response headers or complete OpenAPI models. Current Linking 1.0 adds response configuration and optional typed models; streaming remains outside its JSON API contract. See the current V1 limits.