continuo-python-runtime 0.4.0__py3-none-any.whl → 0.5.0__py3-none-any.whl

continuo_python_runtime/validation/runner.py

@@ -18,6 +18,11 @@ Dispatches on ``VALIDATION_OP`` env var (default ``build_from_sql``):
   that dropped a column the script reads fails the release gate, then the output
   table is materialized empty from the declared typed columns and the declared
   physical layout.
+- ``check_binds``: for a dbt test's compiled SQL (``CANDIDATE_SQL_URI``, fetched
+  the same way as ``build_from_sql``). EXPLAINs it against the candidate schema
+  via the engine adapter and creates nothing — a test whose compiled SQL names
+  a column a candidate change dropped or renamed fails the release at its
+  source, before any table is built.
 
 The engine adapter is discovered from the single installed
 ``continuo_engine.adapters`` entry point — each runner image installs exactly one.
@@ -108,7 +113,7 @@ def load_candidate_spec() -> dict:
     return spec
 
 
-_NODE_OPS = ("build_from_sql", "clone_from_prod", "build_from_columns")
+_NODE_OPS = ("build_from_sql", "clone_from_prod", "build_from_columns", "check_binds")
 _SCHEMA_OPS = ("ensure_schema", "drop_schema")
 
 
@@ -116,10 +121,13 @@ def main() -> None:
     """Run one validation op end to end; exits non-zero on failure.
 
     Node ops (``build_from_sql``/``clone_from_prod``/``build_from_columns``)
-    materialize one empty node table and require ``TABLE_NAME``. Schema ops
-    (``ensure_schema``/``drop_schema``) act on the whole candidate schema —
-    the executor schedules them as one-shot engine-image Jobs to own the
-    candidate-schema lifecycle without connecting to the warehouse itself —
+    materialize one empty node table and require ``TABLE_NAME``. ``check_binds``
+    is also a node op and requires ``TABLE_NAME`` (for identity only, in the
+    result block's ``unique_id``) but creates nothing: it bind-checks a dbt
+    test's compiled SQL against the candidate schema with the engine's EXPLAIN.
+    Schema ops (``ensure_schema``/``drop_schema``) act on the whole candidate
+    schema — the executor schedules them as one-shot engine-image Jobs to own
+    the candidate-schema lifecycle without connecting to the warehouse itself —
     and take no table.
     """
     logging.basicConfig(
@@ -139,7 +147,7 @@ def main() -> None:
     if op in _NODE_OPS:
         table = _require("TABLE_NAME")
         unique_id = _node_id() or f"model.{table}"
-        if op == "build_from_sql":
+        if op in ("build_from_sql", "check_binds"):
             try:
                 raw_sql = load_candidate_sql()
             except Exception as exc:
@@ -150,7 +158,7 @@ def main() -> None:
             if not raw_sql:
                 logger.error(
                     "CANDIDATE_SQL_URI is unset or the object is empty for a "
-                    "build_from_sql node; cannot validate"
+                    "%s node; cannot validate", op
                 )
                 print(result.result_block("error", "CANDIDATE_SQL_URI is unset or empty",
                                           unique_id=unique_id), flush=True)
@@ -238,6 +246,12 @@ def main() -> None:
             if op == "build_from_sql":
                 assert candidate_sql is not None, "candidate_sql must be set for build_from_sql"
                 adapter.build_empty_from_sql(schema, table, candidate_sql)
+            elif op == "check_binds":
+                # A dbt test: EXPLAIN its compiled SQL against the candidate
+                # schema. A dropped or renamed column fails here; no table is
+                # created and no row is read.
+                assert candidate_sql is not None, "candidate_sql must be set for check_binds"
+                adapter.check_binds(candidate_sql)
             elif op == "build_from_columns":
                 assert spec is not None, "spec must be set for build_from_columns"
                 if csv_source:

{continuo_python_runtime-0.4.0.dist-info → continuo_python_runtime-0.5.0.dist-info}/METADATA

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: continuo-python-runtime
-Version: 0.4.0
+Version: 0.5.0
 Summary: Runtime harness, contract tooling, and CI lint for Continuo python nodes.
 Author: Simone Carolini
 Maintainer: Simone Carolini
@@ -11,11 +11,11 @@ Classifier: Development Status :: 4 - Beta
 Classifier: Intended Audience :: Developers
 Classifier: Programming Language :: Python :: 3.14
 Requires-Python: >=3.14
-Requires-Dist: boto3==1.43.59
-Requires-Dist: continuo-engine-contract==0.7.2
-Requires-Dist: pyarrow==25.0.0
+Requires-Dist: boto3==1.43.85
+Requires-Dist: continuo-engine-contract==0.7.3
+Requires-Dist: pyarrow==25.0.1
 Requires-Dist: pyyaml==6.0.3
-Requires-Dist: sqlglot==30.15.0
+Requires-Dist: sqlglot==30.17.0
 Description-Content-Type: text/markdown
 
 # Continuo Python Runtime
@@ -32,7 +32,7 @@ and register the release with Continuo.
 
 ## What this repo is
 
-Four artifacts come out of this repository:
+Five artifacts come out of this repository:
 
 - **The `continuo-python-runtime` PyPI package** — the `continuo-runtime` CLI
   (`validate` / `merge` / `hash` / `lint` / `run` / `validation-op`) and the
@@ -41,6 +41,13 @@ Four artifacts come out of this repository:
 - **The `continuo-engine-contract` PyPI package** — the `WarehouseAdapter`
   port, the contract schema, the shared SQL/type/config guards, and the
   sentinel result-block format. Adapter authors outside this repo pin it.
+- **The two engine-adapter PyPI packages** (`continuo-postgres-adapter`,
+  `continuo-trino-adapter`) — one `WarehouseAdapter` implementation per
+  warehouse engine, each published independently under the same tag. A
+  domain repo normally never installs these directly (the engine image
+  already has the matching one baked in); they exist as standalone PyPI
+  packages for the "build your own container" shape (see below) and for
+  third-party adapter authors to reference.
 - **Per-engine base images**, one per warehouse engine
   (`continuo-python-runtime-postgres`, `continuo-python-runtime-trino`), that
   domain repos build `FROM`. Each image bakes in the runtime and a single
@@ -50,10 +57,11 @@ Four artifacts come out of this repository:
 - **`template/`** — a copy-ready domain repo: `Dockerfile`, `contracts/`,
   `scripts/`, and the `release.yml` CI/CD workflow.
 
-One `vX.Y.Z` git tag releases all of it: `publish-pypi.yml` builds both
-distributions into a single `dist/` and publishes them together, and
-`images.yml` builds and pushes both engine images multi-arch under the same
-tag.
+One `vX.Y.Z` git tag releases all of it: `publish-pypi.yml` builds all four
+PyPI distributions into a single `dist/` and publishes them together, and
+`images.yml` builds and pushes both engine images — each installing its
+matching pinned adapter version from that same release — multi-arch under
+the same tag.
 
 ### What this repo owns
 
@@ -70,22 +78,27 @@ validation-side port, adapter class, entry-point group, or image. One
 | --- | --- | --- | --- |
 | `continuo-python-runtime` | `continuo_python_runtime` | this repo (root) | Harness (CLI, `conform()`, `RunContext`, error taxonomy) **and** the validation runner (`continuo-runtime validation-op`). Published to PyPI. |
 | `continuo-engine-contract` | `continuo_engine_contract` | this repo, `contract/` | The `WarehouseAdapter` port, contract schema, the SQL/type/config guards adapters must run, and the result-block format. Published to PyPI. |
-| `continuo-python-runtime-postgres` | `continuo_python_runtime_postgres` | this repo, `adapters/postgres/` | `PostgresAdapter` — one class, both roles. **Not published to PyPI** — built from source into the image. |
-| `continuo-python-runtime-trino` | `continuo_python_runtime_trino` | this repo, `adapters/trino/` | `TrinoAdapter` — one class, both roles, for Trino/Iceberg. **Not published to PyPI** — built from source into the image. |
+| `continuo-postgres-adapter` | `continuo_postgres_adapter` | this repo, `adapters/postgres/` | `PostgresAdapter` — one class, both roles. Published to PyPI. |
+| `continuo-trino-adapter` | `continuo_trino_adapter` | this repo, `adapters/trino/` | `TrinoAdapter` — one class, both roles, for Trino/Iceberg. Published to PyPI. |
 
 All four are uv workspace members (`[tool.uv.workspace]` in the root
 `pyproject.toml`), so `uv sync --all-packages --all-groups` at the repo root
 installs everything for local development.
 
-**Only `continuo-python-runtime` and `continuo-engine-contract` are published
-to PyPI.** The two engine adapters are built **from source into the engine
-images**: `Dockerfile.postgres` and `Dockerfile.trino` install them out of the
-build context, so each image ships exactly one adapter and the runtime
-discovers it through the `continuo_engine.adapters` entry-point group at run
-time. Nothing installs them from an index — the harness package does not
-depend on them, and domain repos get their adapter by building `FROM` a
-published base image. They are still built, type-checked, and tested by CI on
-every change.
+**All four packages in the table above are published to PyPI**, under the
+same `vX.Y.Z` tag. The two engine images then **install the matching pinned
+adapter version from PyPI** — `Dockerfile.postgres` installs
+`continuo-postgres-adapter==X.Y.Z`, `Dockerfile.trino` installs
+`continuo-trino-adapter==X.Y.Z` — rather than building it from this repo's
+source tree, so each image still ships exactly one adapter and the runtime
+still discovers it through the `continuo_engine.adapters` entry-point group
+at run time. The image **name** (`continuo-python-runtime-<engine>`) and the
+adapter's pip **distribution** name (`continuo-<engine>-adapter`) are two
+different artifacts of the same adapter — same engine, same version, same
+runtime behavior, different packaging; see "Build your own container" below
+for a build shape that installs the pip package directly instead of `FROM`
+the image. All four packages are still built, type-checked, and tested by CI
+on every change.
 
 ### The result block is a frozen wire contract
 
@@ -262,26 +275,46 @@ A domain repo picks its warehouse engine by which base image it builds
 `FROM`:
 
 ```dockerfile
-FROM ghcr.io/carolsimone/continuo-python-runtime-postgres:v0.4.0
+FROM ghcr.io/carolsimone/continuo-python-runtime-postgres:v0.5.0
 # or
-FROM ghcr.io/carolsimone/continuo-python-runtime-trino:v0.4.0
+FROM ghcr.io/carolsimone/continuo-python-runtime-trino:v0.5.0
 ```
 
 The engine is part of the image **name**; the tag is the bare version, so
 Continuo's Helm chart can pin an image as `<name>:vX.Y.Z@sha256:<digest>`.
 
-Each image bakes in exactly one `WarehouseAdapter` for that engine — installed
-from this repo's `adapters/postgres/` or `adapters/trino/` package (see the
-table above) — registered under the `continuo_engine.adapters` entry-point
-group (entry names `postgres` / `trino`). The runtime discovers it via
-`discover_adapter()` at run time, so a single image serves every node in the
-service and the release-time validation Job for it. The executor injects the
-warehouse connection as environment variables (engine-native, e.g.
+Each image bakes in exactly one `WarehouseAdapter` for that engine — the
+pinned PyPI version of the `continuo-postgres-adapter` or
+`continuo-trino-adapter` package built from this repo's `adapters/postgres/`
+or `adapters/trino/` source (see the table above) — registered under the
+`continuo_engine.adapters` entry-point group (entry names `postgres` /
+`trino`). The runtime discovers it via `discover_adapter()` at run time, so a
+single image serves every node in the service and the release-time
+validation Job for it. The executor injects the warehouse connection as
+environment variables (engine-native, e.g.
 `POSTGRES_HOST`/`POSTGRES_DB`/`POSTGRES_USER`) plus the node-selection
 environment (`NODE_ID`, `TABLE_NAME`, `TARGET_SCHEMA`, and optionally
 `CONTRACT_DIR`/`APP_ROOT`) that `continuo-runtime run` reads to dispatch the
 right node's script.
 
+### Build your own container
+
+A domain repo does not have to build `FROM` the published engine image.
+`template/` ships two Dockerfiles for the two build shapes (see
+`template/README.md` § "Choosing a base" for the full comparison):
+
+- **Shape 1 — `template/Dockerfile`** — `FROM` the published engine image
+  (`continuo-python-runtime-<engine>`), as shown above. Simplest; the image
+  already has the runtime and adapter installed and pinned.
+- **Shape 2 — `template/Dockerfile.pip`** — your own base image, installing
+  `continuo-python-runtime` and one `continuo-<engine>-adapter` from PyPI
+  via a hash-locked `requirements.lock` (`template/requirements.lock`). Use
+  this when you must control the base image yourself.
+
+Both shapes end up running the same runtime and the same adapter version;
+which one you pick only changes who controls the base OS layer underneath
+them.
+
 ## Further reading
 
 - `docs/superpowers/specs/2026-07-31-python-runtime-design.md` — this

{continuo_python_runtime-0.4.0.dist-info → continuo_python_runtime-0.5.0.dist-info}/RECORD

@@ -19,11 +19,11 @@ continuo_python_runtime/csv_readers/__init__.py,sha256=9TKvjC37C77uRaJQZuO0--zVj
 continuo_python_runtime/csv_readers/https.py,sha256=tMJ9k5F0b9SAydpon0ZlOznfjvjhF2BBLltyVmvRneE,4998
 continuo_python_runtime/csv_readers/s3.py,sha256=zmvHs3TxlN2alPKrdaHzPyREmkve2nBiAsHRXXe1mE0,2246
 continuo_python_runtime/validation/__init__.py,sha256=hz5oGXsoaUoygR0_pBby9PS6cEfrre518EE0HGB58eE,79
-continuo_python_runtime/validation/runner.py,sha256=AwYbiFrQubxSm1vfxJJpnp7xfekviUW2anw4LRQQ4Rc,13062
+continuo_python_runtime/validation/runner.py,sha256=7pbksf7MXfTNcdklCOkOXg9qfRiJtyI_dbgbL3a9LWk,14072
 continuo_python_runtime/validation/s3.py,sha256=q8nRrT9R7L1-M4dSlDnkL7CUJMPmq86MHY_UKYFlEf8,1785
-continuo_python_runtime-0.4.0.dist-info/METADATA,sha256=JtdvcXJZtH27JKMGd5m1Rm6wvch7MzzrsvvAawOQkCU,17023
-continuo_python_runtime-0.4.0.dist-info/WHEEL,sha256=zOwg4jB6zX2kU910N-cMawjivD6tO8NEWvE12je1bVk,87
-continuo_python_runtime-0.4.0.dist-info/entry_points.txt,sha256=ZvIwSm9f9B9ZmZMf6CyF5Zt4QONn8rqaIk-u-B1CF2Y,70
-continuo_python_runtime-0.4.0.dist-info/licenses/LICENSE,sha256=hfXfFCk-8gnps4YvHA6bjCNaSYqOrq2gAdqkXYycAQc,11345
-continuo_python_runtime-0.4.0.dist-info/licenses/NOTICE,sha256=ykgYyQkAMx3uas90FZHzt0aTca9IgJQCLpZ4d74Pl3U,465
-continuo_python_runtime-0.4.0.dist-info/RECORD,,
+continuo_python_runtime-0.5.0.dist-info/METADATA,sha256=vQisnCASgreJNhw4ryPWuyQvo4dmw6mWEMJH3zZxHx4,18811
+continuo_python_runtime-0.5.0.dist-info/WHEEL,sha256=zOwg4jB6zX2kU910N-cMawjivD6tO8NEWvE12je1bVk,87
+continuo_python_runtime-0.5.0.dist-info/entry_points.txt,sha256=ZvIwSm9f9B9ZmZMf6CyF5Zt4QONn8rqaIk-u-B1CF2Y,70
+continuo_python_runtime-0.5.0.dist-info/licenses/LICENSE,sha256=hfXfFCk-8gnps4YvHA6bjCNaSYqOrq2gAdqkXYycAQc,11345
+continuo_python_runtime-0.5.0.dist-info/licenses/NOTICE,sha256=ykgYyQkAMx3uas90FZHzt0aTca9IgJQCLpZ4d74Pl3U,465
+continuo_python_runtime-0.5.0.dist-info/RECORD,,