continuo-python-runtime 0.7.0__py3-none-any.whl → 0.8.0__py3-none-any.whl

{continuo_python_runtime-0.7.0.dist-info → continuo_python_runtime-0.8.0.dist-info}/METADATA

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: continuo-python-runtime
-Version: 0.7.0
+Version: 0.8.0
 Summary: Runtime harness, contract tooling, and CI lint for Continuo python nodes.
 Author: Simone Carolini
 Maintainer: Simone Carolini
@@ -41,15 +41,16 @@ Five 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
+- **The three engine-adapter PyPI packages** (`continuo-postgres-adapter`,
+  `continuo-trino-adapter`, `continuo-duckdb-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
+  (`continuo-python-runtime-postgres`, `continuo-python-runtime-trino`,
+  `continuo-python-runtime-duckdb`), that
   domain repos build `FROM`. Each image bakes in the runtime and a single
   `WarehouseAdapter` for that engine, and serves both roles that adapter has:
   the node harness (`ENTRYPOINT ["continuo-runtime"]`, `CMD ["run"]`) and the
@@ -57,15 +58,17 @@ Five 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 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.
+One `vX.Y.Z` git tag releases all of it: `publish-pypi.yml` builds all five
+PyPI distributions into a single `dist/`, verifies them (and full engine
+images built from them) on amd64 and arm64, and only then publishes them
+together. It then builds all three engine images natively per architecture —
+each installing its matching pinned adapter version from that same release —
+pulls and smoke-tests the exact pushed digests, and finally gives the verified
+amd64 + arm64 digests one multi-arch tag. See `CONTRIBUTING.md` (Releasing).
 
 ### What this repo owns
 
-This repository owns the entire python-node surface: the engine contract, both
+This repository owns the entire python-node surface: the engine contract, the three
 engine adapters, the validation runner, and the node harness. The former
 `continuo-validation` repository was merged in — there is no longer a separate
 validation-side port, adapter class, entry-point group, or image. One
@@ -80,16 +83,18 @@ validation-side port, adapter class, entry-point group, or image. One
 | `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-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. |
+| `continuo-duckdb-adapter` | `continuo_duckdb_adapter` | this repo, `adapters/duckdb/` | `DuckDBAdapter` — one class, both roles, for DuckDB on a DuckLake (Postgres catalog, Parquet on S3). Published to PyPI. |
 
-All four are uv workspace members (`[tool.uv.workspace]` in the root
+All five 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.
 
-**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
+**All five packages in the table above are published to PyPI**, under the
+same `vX.Y.Z` tag. The three 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
+`continuo-trino-adapter==X.Y.Z` and `Dockerfile.duckdb` installs
+`continuo-duckdb-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
@@ -97,7 +102,7 @@ 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
+the image. All five packages are still built, type-checked, and tested by CI
 on every change.
 
 ### The result block is a frozen wire contract
@@ -149,7 +154,7 @@ the pre-flight check once before your next release; it reports every affected
 read at once:
 
 ```bash
-continuo-runtime validate contracts/ --dialect postgres   # or trino
+continuo-runtime validate contracts/ --dialect postgres   # or trino, duckdb
 ```
 
 The runtime image does not re-run this gate, so a read that passes here is
@@ -281,9 +286,9 @@ A domain repo picks its warehouse engine by which base image it builds
 `FROM`:
 
 ```dockerfile
-FROM ghcr.io/carolsimone/continuo-python-runtime-postgres:v0.7.0
+FROM ghcr.io/carolsimone/continuo-python-runtime-postgres:v0.8.0
 # or
-FROM ghcr.io/carolsimone/continuo-python-runtime-trino:v0.7.0
+FROM ghcr.io/carolsimone/continuo-python-runtime-trino:v0.8.0
 ```
 
 The engine is part of the image **name**; the tag is the bare version, so
@@ -294,7 +299,7 @@ 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
+`trino` / `duckdb`). 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.

{continuo_python_runtime-0.7.0.dist-info → continuo_python_runtime-0.8.0.dist-info}/RECORD

@@ -23,9 +23,9 @@ continuo_python_runtime/csv_readers/s3.py,sha256=zmvHs3TxlN2alPKrdaHzPyREmkve2nB
 continuo_python_runtime/validation/__init__.py,sha256=hz5oGXsoaUoygR0_pBby9PS6cEfrre518EE0HGB58eE,79
 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.7.0.dist-info/METADATA,sha256=Uo2XMCZawYbKgpER3qDn-eF_0cKJUZTultaxxcBAhuQ,19281
-continuo_python_runtime-0.7.0.dist-info/WHEEL,sha256=W3fkpkm7-wf9vBI5Z-7s0eWkeM-spu78I8Neb98DeEg,87
-continuo_python_runtime-0.7.0.dist-info/entry_points.txt,sha256=ZvIwSm9f9B9ZmZMf6CyF5Zt4QONn8rqaIk-u-B1CF2Y,70
-continuo_python_runtime-0.7.0.dist-info/licenses/LICENSE,sha256=hfXfFCk-8gnps4YvHA6bjCNaSYqOrq2gAdqkXYycAQc,11345
-continuo_python_runtime-0.7.0.dist-info/licenses/NOTICE,sha256=ykgYyQkAMx3uas90FZHzt0aTca9IgJQCLpZ4d74Pl3U,465
-continuo_python_runtime-0.7.0.dist-info/RECORD,,
+continuo_python_runtime-0.8.0.dist-info/METADATA,sha256=q2tb518F9n_Bo4LIzbhhGSGm5yJPxbrOkWJKJ6y9gxQ,19874
+continuo_python_runtime-0.8.0.dist-info/WHEEL,sha256=W3fkpkm7-wf9vBI5Z-7s0eWkeM-spu78I8Neb98DeEg,87
+continuo_python_runtime-0.8.0.dist-info/entry_points.txt,sha256=ZvIwSm9f9B9ZmZMf6CyF5Zt4QONn8rqaIk-u-B1CF2Y,70
+continuo_python_runtime-0.8.0.dist-info/licenses/LICENSE,sha256=hfXfFCk-8gnps4YvHA6bjCNaSYqOrq2gAdqkXYycAQc,11345
+continuo_python_runtime-0.8.0.dist-info/licenses/NOTICE,sha256=ykgYyQkAMx3uas90FZHzt0aTca9IgJQCLpZ4d74Pl3U,465
+continuo_python_runtime-0.8.0.dist-info/RECORD,,