datacontract-cli: one YAML contract that lints, tests and describes a data product

The contract file holds connection details, schema, service levels and quality rules

The README works through a real contract file, orders-v1.odcs.yaml, hosted at datacontract.com, and the structure it describes is the whole idea in one file. There is a servers section with endpoint details to a Postgres database, a schema section for the structure and semantics of the data, service levels and quality attributes describing expected freshness and number of rows, and a set of models, in this case line_items and orders. The claim that follows is the useful part: the contract contains all information needed to connect to the database and check that the actual data meets the defined schema specification and quality expectations. That is what separates a data contract from a schema dump. A schema says what the columns are. A contract also says where the data is, what it should contain, and how fresh it is supposed to be, which is enough information for a machine to run the check.

What the test run actually reports

Running the tests produces a table with a Result column, a Check description, a Field path and a Details column, and the README shows the output for the orders contract. The checks are specific and mechanical rather than statistical. There is a check that a field is present, a check that the field has a given physical type, for example that line_item_id has physical type UUID and that price has physical type INTEGER, checks that a field has no missing values, and checks that a primary key or unique field has no duplicate values. There are length checks, with a minimum and a maximum length of 10 on customer_id, and there is a model level check that orders has row_count greater than 100000. Every row in the example passed, and the pass or fail verdict is what a CI job would gate on.

Installing and running against Postgres

The README installs the CLI with uv, pinning a Python version, or points at the Docker image. The install command includes the all extra, which is what pulls in the adapters for every supported data source rather than just the one you need. The test run then needs credentials, and the pattern shown is environment variables named after the source, with a Postgres username and password exported before the command. The command itself takes the contract URL as its argument, and the output opens with the server being tested, naming the environment, the type, the host, the port, the database and the schema. The fact that the contract URL is the only input is the point of the design, because the same command works against any contract in any environment once the credentials are in place.

$ uv tool install --python python3.11 --upgrade 'datacontract-cli[all]'

$ export DATACONTRACT_POSTGRES_USERNAME=datacontract_cli.egzhawjonpfweuutedfy
$ export DATACONTRACT_POSTGRES_PASSWORD=jio10JuQfDfl9JCCPdaCCpuZ1YO
$ datacontract test https://datacontract.com/orders-v1.odcs.yaml

A CLI, a CI step and a library, and what ODCS actually pins down

The README states that the tool is written in Python and that it can be used as a standalone CLI tool, in a CI/CD pipeline, or directly as a Python library. Those three modes are why the package is published on PyPI with an all extra, since the adapter set is the bulk of the dependency footprint and a library user may want only one. The standard it builds on is the Open Data Contract Standard, and the README says the tool natively supports ODCS to lint data contracts, connect to data sources, execute schema and quality tests, and export to different formats. Linting is a separate concern from testing and worth noting on its own, because a contract that fails to lint is a contract whose meaning is ambiguous, and catching that in review is cheaper than discovering it in a failing test.

The scope of adapters is what decides whether it fits your stack

The project description names Snowflake, Databricks, BigQuery, Kafka and 15 more, and the topics list carries bigquery, databricks, snowflake, kafka, dbt, odcs, data-mesh, data-product, data-quality and data-governance, which is a good map of the intended use. The README's example uses a Postgres endpoint, so the traditional warehouse adapters sit alongside the modern lakehouse ones rather than replacing them. The tool also detects breaking changes, which is the operation that matters most in practice for a contract driven workflow, and it exports to different formats, which is how a contract written in ODCS reaches a consumer that wants something else. The repository layout shows the working surfaces, with examples/ split into business-definitions, imports, orders, testing and user_interactions, plus a set of top level scripts that generate and refresh documentation, including update_command_docs.py, update_config_options.py and update_excel_template.py.

Packaging: a 3.10 to 3.14 range, and a container built on a hardened base

The pyproject.toml declares version 1.2.6, the MIT licence and requires-python covering Python 3.10 through 3.14, with the classifiers for each of those versions and a comment reminding the maintainers to keep them in sync. The development status is classified as Production/Stable and the operating system as independent. There is a deliberate detail in the metadata, a comment explaining that no MIT classifier is present because PEP 639 makes the SPDX license expression and the license classifiers mutually exclusive, and setuptools 77 or newer errors out when both are present. That is the kind of note that saves a contributor an afternoon. The Dockerfile is more opinionated still, building on a Docker Hardened Image with a socket firewall, copying uv from a pinned 0.11.15 image, creating a virtual environment, installing with pip through the firewall, and copying the finished environment into a runtime image with no shell, no package manager and no perl, running as the nonroot user with the entrypoint set to datacontract.

The container build has a prerequisite you will hit immediately

The Dockerfile comment says it in capitals. The base image comes from dhi.io, and the file explains that the socket firewall free variant is signed, ships an SBOM and VEX, has tighter CVE patch SLAs than upstream Debian, and proxies pip and uv installs through the firewall to block malicious dependencies at build time. Then it says the requirement plainly: docker login dhi.io with a Docker Hub account that has DHI access is required. This is a genuine operational decision and not a detail to skip. A team that cannot obtain DHI access, or that has a policy against a specific base image, cannot build the published Dockerfile as written, and the fallback is to build the image yourself from the Python base and the pyproject, which loses the firewall and the hardened base but keeps the tool working. The comment on the runtime stage notes that nothing in the all extra shells out, which is why the shell-less runtime image works.

Release pace, documentation and the agent-facing extras

The releases move quickly: v1.2.4 on 2026-10-06, v1.2.5 on 2026-10-12 and v1.2.6 on 2026-10-13, with the last push to the repository on 2026-10-14. Three patch releases within eight days suggests a team shipping continuously rather than batching. The documentation is a separate site at docs.datacontract.com with the quickstart, the commands reference, best practices, and pages on custom export and import and on release notes, and the README carries an llms.txt and llms-full.txt pair for machine readers, along with a pointer to a Data Contract Skills repository for coding agents. The repository itself contains AGENTS.md and CLAUDE.md, and a context7.json. A tool that ships agent skills and machine-readable documentation is telling you something about who it expects to be used by.

Editorial conclusion

datacontract-cli suits a data team that has agreed on a contract format and wants the contract enforced in CI rather than documented, and that needs the same checks to run against several warehouses without rewriting them per platform. It is the wrong tool for a team with no agreed contract standard yet, because the tool's value is entirely in the contract file rather than in the test runner, and a poor fit where the data product is a stream that the supported adapters do not cover. Before adopting it, read the ODCS specification the tool natively supports, decide which adapter you will target among those the description names, and note that the Docker image is built on a hardened base that requires docker login dhi.io with Docker Hub DHI access, which is a deployment detail you will hit on the first container build.

Frequently asked questions

Official sources

1. datacontract/datacontract-cli on GitHub
2. License: MIT
3. Project website
4. README
5. Releases