Skip to main content

kumo-connectors

Shared data-source connectors for the kumo-relational-client client and its model engines. One place that knows how to reach each warehouse, so the client (flat table reads) and the Kumo Relational driver (warehouse connections for its graph samplers) don't each carry their own copy.

It provides:

  • connect(backend, **kwargs): open a connection to sqlite / duckdb / snowflake / databricks / postgres (one driver per backend).
  • read(source, **kwargs) -> DataFrame: read a table or query as a flat pandas DataFrame (also handles local DataFrames / CSV / Parquet, and s3 object URIs: read('s3', path='s3://bucket/table.parquet', storage_options=...)).
  • read_table(connection, table=…, query=…) -> DataFrame: driver-agnostic fetch over an open connection, in that connection's own session.
  • quote_ident(ident, char='"') and resolve_sql(table=…, query=…): SQL identifier quoting and a safe table/query guard.

File reads (local and s3) accept .csv / .txt (optionally compressed) and .parquet / .pq / .parq, plus a directory as a Parquet dataset. Any other suffix is rejected with INVALID_CONNECTOR_ARGS rather than parsed as CSV; pass format='csv' or format='parquet' to read a file whose name carries no recognised suffix.

The two file-backed backends, sqlite and duckdb, accept database= and uri= as aliases for the same argument (supplying both is an error). The remote backends, snowflake, databricks, and postgres, are addressed by connection keywords instead, and reject any their driver does not declare; driver_options={...} passes anything else straight through. The snowflake backend reuses an active Snowpark session when no authentication arguments are given; a borrowed session cannot be reconfigured, so passing session-scoped arguments such as schema= alongside it is an error.

The postgres backend uses psycopg and accepts a PostgreSQL URI, a libpq conninfo string, explicit connection keywords, or standard PG* environment variables. Provider-specific requirements such as TLS must be passed explicitly (for example, sslmode='require' for a direct Lakebase connection).

table= accepts only plain, unquoted, dot-separated ASCII identifiers, and interpolates them as written, so they are subject to each backend's default case folding (Snowflake upper-cases; Databricks and PostgreSQL lower-case). A name that needs quoting (spaces, non-ASCII characters, a leading digit) is rejected with INVALID_CONNECTOR_ARGS. A reserved word such as select is a plain identifier by that rule, so it is accepted here and instead fails at execution as QUERY_FAILED. Either way, reach the table through query= with quote_ident, choosing the quote character your backend uses (" for SQLite/DuckDB/Snowflake/PostgreSQL, ` for Databricks):

read('duckdb', database='w.db', query=f'SELECT * FROM {quote_ident("café")}')

Failures raised by connect / read / read_table surface as ConnectorError with a stable code: UNKNOWN_CONNECTOR, INVALID_CONNECTOR_ARGS, CONNECT_FAILED, QUERY_FAILED, READ_FAILED, or NOT_FOUND, with the original driver exception chained as __cause__. Two cases stay unwrapped by design: a missing optional driver raises MissingBackendError, and a broken or incompatible driver installation raises ImportError (consumers map it to their own broken-install category, e.g. kumo-relational-client's DRIVER_LOAD_FAILED).

Pure-python. Database drivers are optional extras:

pip install "kumo-connectors[sqlite]"      # or [duckdb] / [snowflake] / [databricks] / [postgres] / [s3] / [all]

Consumers depend on it and surface these extras under their own name, e.g. kumo-relational-client[snowflake] and kumo_relational_engine[databricks] both resolve the corresponding kumo-connectors extra.

Local development

pip install -e ".[sqlite,duckdb,test]"
pytest tests

Metadata

Release files for kumo-connectors 1.0.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for kumo-connectors 1.0.0
File Size Uploaded Provenance
kumo_connectors-1.0.0.tar.gz 38.2 kB With provenance Details

Built distribution (wheel)

Table of built distributions (wheels) for kumo-connectors 1.0.0
File Interpreter ABI Platform
kumo_connectors-1.0.0-py3-none-any.whl Python 3 none any Details

Total release size: 69.9 kB

Release files / kumo_connectors-1.0.0.tar.gz

Download URL kumo_connectors-1.0.0.tar.gz
Size 38.2 kB
Tags Source
SHA-256 checksum
How to use checksums
3b963797192c4f1569ba7c7a09ccdc327dedbdf1f1720383352c24b71293c47e
BLAKE2b-256 checksum
How to use checksums
c9a5b162a1b61982dc58e0fafcc85fc54460b0a9365ed68e347406ba5a1961dd
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 8, 2026.

Transparency log

Release files / kumo_connectors-1.0.0-py3-none-any.whl

Download URL kumo_connectors-1.0.0-py3-none-any.whl
Size 31.6 kB
Tags Python 3
SHA-256 checksum
How to use checksums
f440a3c88aa2328ca5e2bdec9ecc43e392d3a54f3720c0b0587d9f3a2436d030
BLAKE2b-256 checksum
How to use checksums
271bdc99919b75c90127152cbfbb65a4409bec64ff799f19c184fb73f60a9d4e
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 8, 2026.

Transparency log

Security for kumo-connectors 1.0.0

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

Full provenance

All 2 files in this release have been uploaded with provenance metadata.

Select from 2 files

Attestation for kumo_connectors-1.0.0.tar.gz

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 8, 2026.

Transparency log

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page