vibedata-dlt-duckdb-studio

DuckDB Studio execution unit for the VibeData dlt runtime — the installed distribution for DuckDB / MotherDuck domains running in the Studio-local intent venv. It exposes the runtime contract from vibedata-dlt-duckdb-core as the stable, unit-agnostic import:

from vibedata.dlt.duckdb import setup_environment, finalize

finalize is the core implementation unchanged. setup_environment wraps it with the two behaviours specific to the Studio agent container.

Credentials. On a MotherDuck domain it mints the acting user's PAT from Studio's credential broker and sets motherduck_token before dlt opens any md: connection. A MotherDuck run that cannot obtain a token raises MotherduckCredentialError rather than proceeding — without a token, duckdb falls through to an interactive SSO device-code flow that cannot complete in a headless container. A DuckDB-local domain has no credential to resolve, so this half is a no-op there.

Destination identity. On either platform it binds the destination to the Intent's Ephemeral Workspace under dlt's own config name — from VD_EPHM_MOTHERDUCK_DATABASE on MotherDuck, from VD_EPHM_DUCKDB_LOCAL_PATH on DuckDB-local (falling back to the legacy alias VD_EPHM_DUCKDB_PATH) — so the generated pipeline stays plain destination="motherduck" or destination="duckdb" and reads no VD_* variable itself. A run whose sandbox cannot be resolved raises (MotherduckSandboxMissingError / DuckdbSandboxMissingError) instead of letting dlt pick its own default: for duckdb that default is <pipeline_name>.duckdb relative to the working directory, which reports a successful load while leaving the Ephemeral Workspace empty (VD-3849 on MotherDuck, VD-4884 on DuckDB-local).

Install this package; it pulls in vibedata-dlt-duckdb-core (and transitively vibedata-dlt-core). Exactly one DuckDB unit is installed per environment, selected at provisioning time.