Installation

ContractForge is published as independent Python packages. Install the platform-neutral core plus the adapter for the runtime you want to plan, render or execute.

The package boundary is intentional:

• contractforge-core owns contract models, semantic validation, planning and neutral evidence concepts.
• each adapter package owns platform APIs, native artifacts, deployment helpers and runtime-specific evidence filling.
• contractforge-ai is optional and uses the same deterministic core and adapter planners.

Install by target runtime

# Databricks
pip install contractforge-core contractforge-databricks

# AWS Glue / Iceberg
pip install contractforge-core contractforge-aws

# Snowflake
pip install contractforge-core contractforge-snowflake

# Microsoft Fabric
pip install contractforge-core contractforge-fabric

# GCP BigQuery / BigLake
pip install contractforge-core contractforge-gcp

# ContractForge AI companion
pip install contractforge-core contractforge-ai

For a local machine that validates and compares projects across every adapter:

pip install \
  contractforge-core \
  contractforge-databricks \
  contractforge-aws \
  contractforge-snowflake \
  contractforge-fabric \
  contractforge-gcp \
  contractforge-ai

Install is not the same as runtime delivery

pip install makes a package available to the Python process running the CLI or library code. Execution platforms have their own package-delivery rules. Use PyPI first where the runtime can resolve it safely; use wheels when the runtime needs explicit artifacts; use ZIP only where the platform requires staged Python imports.

Platform	Published package	Preferred runtime delivery	Wheel or ZIP fallback	Where ContractForge code runs
Databricks	contractforge-core + contractforge-databricks from PyPI.	Install the packages from PyPI on the job, cluster, notebook environment or workspace package path.	Attach uploaded wheels when the workspace cannot reach PyPI or a release must be pinned from CI artifacts. ZIP is not the normal Databricks path.	Inside Databricks jobs/notebooks with Spark and Delta supplied by Databricks Runtime.
AWS Glue / Iceberg	contractforge-core + contractforge-aws from PyPI for local or CI deploy tooling.	Publish generated artifacts and S3-hosted wheels, then configure Glue jobs with those wheel dependencies.	Public PyPI can work only when the Glue job has outbound package access. Private VPC jobs should use S3 wheelhouse dependencies. ZIP is not the stable Glue path.	Inside AWS Glue Spark jobs; Athena/Iceberg evidence DDL can also be applied by adapter deployment helpers.
Snowflake	contractforge-core + contractforge-snowflake from PyPI for local or CI deploy tooling.	SQL/task graph artifacts run natively in Snowflake. Hosted Snowpark procedure execution uses staged ZIP imports for the core and adapter libraries.	Build wheels from the release, then stage Snowflake-compatible ZIP imports for procedure execution. Do not rely on runtime PyPI resolution for custom ContractForge modules inside Snowflake.	In Snowflake SQL warehouses and, for the hosted procedure path, inside Snowpark Python procedures.
Fabric	contractforge-core + contractforge-fabric from PyPI.	Install from PyPI in the Fabric notebook/runtime environment used by the deployed Lakehouse notebook.	Attach or install built wheels when PyPI is unavailable or the workspace must use CI-produced artifacts. ZIP is not the normal Fabric path.	Inside Fabric Lakehouse notebooks using the configured Lakehouse and workspace context.
GCP BigQuery / BigLake	contractforge-core + contractforge-gcp from PyPI for local, CI or runner-side tooling.	BigQuery SQL, load jobs and Workflows are generated native artifacts; install the adapter where deployment/smoke helper Python commands run.	Use wheels for private runners or pinned CI artifacts. Dataflow/custom Python runners may need their own packaging decision. ZIP is not part of the stable BigQuery/Workflows path.	Usually outside BigQuery, in the CLI/CI runner that renders and submits jobs; BigQuery and Workflows execute native artifacts.
ContractForge AI	contractforge-core + contractforge-ai from PyPI, plus any adapters to validate.	Local or CI Python environment.	Wheels are useful for offline validation of unreleased builds. ZIP is not used.	In the AI planning/review process; deterministic core and adapter planners still validate every generated project.

Adapter commands after install

Each adapter exposes its own CLI, but command names follow the same vocabulary:

Platform	CLI
Databricks	contractforge-databricks
AWS	contractforge-aws
Snowflake	contractforge-snowflake
Fabric	contractforge-fabric
GCP	contractforge-gcp

Examples:

contractforge validate contracts/bronze/b_orders.ingestion.yaml

contractforge-databricks render-project-bundle examples/real-world/usgs-earthquake-rest-medallion/project.yaml

contractforge-aws deploy-project examples/real-world/usgs-earthquake-rest-medallion/project.yaml --run --wait

contractforge-snowflake deploy-project examples/real-world/usgs-earthquake-rest-medallion/project.yaml --dry-run --summary-only

contractforge-fabric run-project examples/real-world/usgs-earthquake-rest-medallion/project.yaml --environment-key fabric

contractforge-gcp deploy-project examples/real-world/usgs-earthquake-rest-medallion/project.yaml --deploy-orchestration --run-orchestration --wait-orchestration --readback-orchestration

Development from this repository

For local development, build each package independently:

uv build --wheel

cd adapters/databricks
uv build --wheel

cd ../aws
uv build --wheel

cd ../snowflake
uv build --wheel

cd ../fabric
uv build --wheel

cd ../gcp
uv build --wheel

cd ../../ai
uv build --wheel

Core must not depend on adapter SDKs. Adapter wheels depend on contractforge-core and own their platform-specific dependencies.