Skip to content

Apizr 0.4.0

Release preparation — not published. Latest published stable: 0.3.0.

Apizr connects selected Python functions to AI agents through MCP or exposes them as REST APIs. Version 0.4.0 extends that compiler with remote Git sources, isolated optional plugins and an explicitly authorized delivery workflow. Python 3.11–3.14 remains supported; the minimal core still depends only on Pydantic.

These notes describe the integrated 0.4.0 scope. They do not announce available 0.4.0 packages. To evaluate it now, use the development installation and retain the source commit. For published packages, use the stable Quickstart.

Upgrading an existing workflow? Start with Migrate from 0.3 to 0.4.

Analyze a project locally or from Git

  • Call readiness, planning and REST/MCP generation directly through the Python compiler API, shared with the CLI.
  • Use an explicitly selected apizr.toml for local roots, scan/graph options and policy paths. Explicit CLI options take precedence; no project file is loaded automatically.
  • Analyze public HTTPS or private SSH repositories at a required branch, tag or commit. SSH uses an explicitly prepared agent and known-hosts file. A generation keeps one acquired snapshot and its resolved commit through analysis and rendering.
  • Grant access before source reads through the common operator policy. Fetching Git and analyzing its snapshot are separate permissions. Readiness does not grant access or select public functions.

Keep integrations outside the core

Extensions run in separate Python environments and fresh supervised processes. The core does not import them. Plugin commands support local or HTTPS wheel installation with a required hash, locked local dependencies, explicit activation/invocation, controlled updates and safe removal of an inactive, unused version.

Project declarations and locks make installation inputs explicit. A versioned catalog and profiles prepare reviewed choices; neither a catalog nor a lock grants permission or automatically activates a plugin. Artifact integrity does not establish author trust.

Optional plugin What it does Boundary
apizr-mcp Local stdio analysis, readiness and exposure planning Captured source scope and operator authority; no Git acquisition, generation or delivery tools
apizr-oci Build REST/MCP service images and push a verified image to an explicit registry Immutable image identity, explicit Docker/authentication inputs and independent build/publication grants
apizr-attest Sign, timestamp and verify delivery receipts; publish, discover and fetch OCI-linked proofs Independent signing and publication grants; explicit identity, trust and proof digest

A generated business MCP server calls your selected functions. The Apizr analysis MCP server inspects your project and prepares plans. Installing the core's mcp extra does not install or activate apizr-mcp.

Compatibility changes to apply

  1. Repository scan, graph, readiness and expose commands now require --operator-policy with an exact source.analyze grant. Their Python filesystem APIs require the same policy. Git commands need git.fetch too.
  2. Managed image build, signing and publication require their own operator grants. Project configuration, exposure selection and plugin activation do not grant these rights. See the permission map.
  3. Regenerate existing MCP bundles to receive the structuredContent fix. Non-object returns become an object such as {"result": 25.0}; dictionary returns are unchanged. REST and Python return values are unchanged. Upgrading the compiler alone does not update a previously generated server.

Single-file/notebook inspect, generate rest/mcp, execute, and the historical YAML pipeline remain supported. Repository analysis stays static. Existing readiness/exposure contracts, explicit function selection and execution modes retain their roles; no migration installs plugins or deploys a service automatically.

Limits and planned follow-up

Plugins and generated services remain trusted code, not sandboxes. Local process controls do not isolate host files or network access. OCI service images are different from governed execution worker images. A failed or interrupted transfer does not prove remote rollback; an unconfirmed remote state is not success.

Git acquisition retains its bounded-process and export restrictions: no checkout, submodule or LFS materialization, source imports or application dependency installation. An authorized branch name can move; retain the resolved commit. A chosen subdirectory does not restrict every Git object transferred.

The following work is explicitly deferred, not included in 0.4.0:

  • 0.4.1: application dependencies/resources, a shared delivery manifest, multiple destinations, mandatory proof and Docker Hub/Trunx qualification.
  • 0.4.2: delivery from MCP, Postman export/synchronization, GitHub/GitLab integrations, initialization/diagnostics/completion and a Homebrew tap.

See the tracked delivery scope. The disposable registry proofs do not qualify third-party registries or establish catalog admission.

Publication status

The implementation is integrated; the exact release distributions have not yet been finalized and published. Core and official plugin candidates declare 0.4.0; their version metadata does not establish publication. They are not the stable PyPI 0.3.0 files.

Before this page can become a release record, the publication procedure must qualify the final versions and exact artifacts, then verify their published bytes and installation. This section will record the source/tag, successful artifact runs, distribution identities and verification results once they exist. No 0.4.0 release date, tag or checksum is claimed here.