vibedata-dlt-fabric-warehouse-studio

Fabric Warehouse Studio execution unit for the VibeData dlt runtime — the installed distribution for Domains whose Fabric data platform is a Warehouse rather than a Lakehouse, running in the Studio-local intent venv. dlt's own fabric destination does the loading; this unit supplies the two things it cannot get inside a Studio container: a brokered, audience-bound access token in place of a client secret, and a credential for the OneLake staging area the run is configured with, holding the parquet that COPY INTO reads back.

import dlt
from vibedata.dlt.fabric_warehouse import setup_environment, finalize, onelake_staging

setup_environment()
pipeline = dlt.pipeline(pipeline_name="<name>", destination="fabric",
                        staging=onelake_staging(), dataset_name="<schema>")
try:
    pipeline.run(source)
except Exception as e:
    finalize(pipeline, error_message=str(e)); raise
finalize(pipeline)

setup_environment() and finalize() are the whole API — the same pair every execution unit exposes. setup_environment() asserts dlt's fabric destination is patched for token auth, registers the credential-broker token provider, and resolves the staging location. finalize() persists the audit tables and stops there: dlt performs the load itself, so unlike the Lakehouse unit there is nothing left to sync.

The staging location is read from dlt config as [destination.filesystem] bucket_url, overridable through DESTINATION__FILESYSTEM__BUCKET_URL. It must be an abfss:// URL on OneLake naming its workspace by GUID: Fabric's OneLake endpoints reject display names, so a non-GUID is refused at setup. Absent the key there is no staging location and the load goes row by row.

The dlt pin

dlt>=1.30,<1.31. The fabric destination arrived in 1.30 and only speaks client-secret service-principal auth, so this unit patches five of its private seams: the destination's config spec, FabricCredentials.on_partial, FabricCredentials.get_odbc_dsn_dict, FabricSqlClient.open_connection, and FabricCopyFileLoadJob._ensure_fabric_token_initialized. None of those is public API, so a minor bump can move them and the upper bound is a correctness fence rather than caution. mssql and synapse are never touched.

Upstream support for an access token on the Fabric credentials — an access_token field and attrs_before on the connection — would make _spec.py and _patch.py deletable, leaving only staging and bootstrap.