Making Fabric easier to use

Write normal Python and SQL across your Lakehouses and Warehouses. Weaver works out the dependencies, creates the Fabric objects, runs the data work in the right order and records what happened.

Try the Sales example View on GitHub

What Weaver makes easier

Work across Lakehouses and Warehouses as one project

Weaver works out the order between your Python and SQL, including dependencies that cross Fabric items. You do not need another pipeline simply because the next table uses a different engine.

Write Python and SQL without repeating the dependencies

Your Python imports and SQL references already say what depends on what. Weaver uses them directly instead of making you declare the same order in a separate orchestration layer.

Change Fabric structure without loading data

weaver build creates or changes tables, views, shortcuts and other Fabric objects. weaver load runs the data work, so the two jobs do not have to happen together.

Know what happened after a run

Weaver records what loaded, what failed, what was blocked and how far each object got. The next run can use that state instead of starting again or relying on logs.

What a Weaver project looks like

The generated Sales example has Python in a Lakehouse, T-SQL in a Warehouse, a shortcut between them and a check on each side.

Analytics/
workspace-config.yml
workflow.yml

Lakehouse/Landing/
├── Files/
│   └── Sales__Customers.py
├── Tables/
│   └── Sales__Customer.py
└── assumptions/
    └── Sales__CustomerValid.py

Warehouse/Curated/
├── shortcuts.yml
├── Sales.Region.sql
├── Sales.CustomerByRegion.sql
└── assumptions/
    └── Sales.CustomerByRegionValid.sql

Each file sits under the Lakehouse or Warehouse that owns it. A small configuration file says which real Fabric items those names refer to, so the project files stay the same in development and production.

Weaver works out the order

The Sales example as one dependency graph The graph contains dependency edges from the Customers file folder to the Customer Delta table, from Customer to CustomerValid and a Warehouse shortcut, from the shortcut and Region to CustomerByRegion, and from CustomerByRegion to CustomerByRegionValid. LAKEHOUSE / LANDING WAREHOUSE / CURATED Customers Files/Sales · Python folder Customer Sales · Delta table CustomerValid Sales · Assumption Customer Sales · Shortcut Region Sales · Table, T-SQL CustomerByRegion Sales · Table, T-SQL CustomerByRegionValid Sales · Assumption
  • Files
  • Tables
  • Shortcut
  • Assumption
The dependency graph places the Warehouse join after the Lakehouse table it reads, even though the objects are in different Fabric items.

The Warehouse join reads a Lakehouse table through a shortcut. Weaver sees that dependency in the project and runs the Lakehouse work first.

Build this example in your own workspace

Branch your data as well as your code

A Git branch gives you another version of the project files. Weaver Mirror gives you a development branch of the actual Fabric estate.

Your development estate can start from current production data without copying every table. Lakehouse data can remain behind OneLake shortcuts and Warehouse data behind views.

When you need to change part of the estate, build that part in development and leave the rest mirrored. The code and the data can branch together.

See how Mirror works as the project grows

Try it on a small Fabric project

Install Weaver, choose the Sales example, then build, load and test it in your own workspace.

terminal
pip install weaverstack
weaver initialise --workspace Analytics

Read the walkthrough

Weaver is free and open source under the Mozilla Public License 2.0. It runs from a Fabric notebook or from your own machine.