Reference

Reference material is for exact behavior after the shape of a weave is already clear: public imports, configuration keys, environment resolution, executor frames, and backend adapter requirements. The topic guides explain the workflow model; the reference pages pin down names, options, and runtime contracts.

Core References

  • Public API: the import surface most users should rely on.

  • Environments: how persistent execution profiles are defined and resolved.

  • Executors: executor contracts, error frames, dispatch extras, network executors, and custom executor extension points.

  • Backend Adapters: setup for Wove’s built-in bridges into external task systems and custom backend adapter extension points.

Public API

The public API references separate the stable import surface from modules that mainly matter when inspecting internals.

  • wove: package entrypoints including weave, Weave, config, helpers, and exported exceptions.

  • wove.weave: reusable workflow classes and inheritable weave definitions.

  • wove.helpers: data-shaping helpers used inside task graphs.

  • wove.context: context manager implementation behind with weave() as w:.

Configuration And Runtime

Runtime references trace how Wove resolves project defaults, named environments, task-level overrides, and executor instances when work is not running where expected.

  • wove.runtime: process-wide configuration singleton and wove.config(...) behavior.

  • Environments: environment dictionaries, precedence, defaults, and validation rules.

  • wove.environment: executor interfaces, runtime delivery errors, and executor runtime classes.

  • wove.security: network executor request signing and verification helpers.

Dispatch And Remote Execution

Remote execution references separate the direct executor protocol, worker-service flow, backend callback flow, and adapter contract so the two extension shapes do not blur together.

  • Executors: frame protocol, executor lifecycle, and network executors.

  • HTTP/HTTPS Executor: direct request/response transport for worker services.

  • gRPC Executor: generic unary RPC transport for gRPC-based worker services.

  • WebSocket Executor: persistent bidirectional transport for worker services that stream events.

  • Custom Executors: direct executor implementations for project-owned transports or runtimes.

  • Backend Adapters: built-in bridges into Celery, Temporal, Ray, Kubernetes, AWS Batch, Slurm, and similar systems.

  • Custom Backend Adapters: adapter implementations for project-owned task systems.

  • wove.backend: backend callback transport and dispatch payload helpers.

  • wove.integrations: adapter registry, adapter base interface, and worker entrypoints.

  • wove.security: shared security layer for HTTP, gRPC, and WebSocket network executors.

Backend Adapters

Each adapter page shows what Wove submits to that system, what the worker must run, and which executor_config keys matter.

  • Celery: broker-backed worker pools.

  • Temporal: workflow/task-queue execution.

  • Ray: Ray cluster tasks.

  • RQ: Redis Queue workers.

  • Taskiq: async task queues with explicit task registration.

  • ARQ: async Redis worker functions.

  • Dask: distributed Python scheduler workers.

  • Kubernetes Jobs: isolated pod-per-task execution.

  • AWS Batch: managed batch compute jobs.

  • Slurm: HPC batch scheduling.

  • Custom Backend Adapters: project-local bridges into systems Wove does not ship with.