Source install fails because adbc-driver-flightsql requires ADBC_FLIGHTSQL_LIBRARY

[chenrui333]

Summary

Installing dbt-mcp==0.2.20 from the published source distribution currently fails in source-build environments because a transitive dependency requires a prebuilt Flight SQL shared library path at build time.

The failing chain is:

• dbt-mcp==0.2.20
• depends on dbt-sl-sdk[sync]==0.11.0
• dbt-sl-sdk==0.11.0 depends on adbc-driver-flightsql>=0.11.0
• adbc-driver-flightsql source build aborts unless ADBC_FLIGHTSQL_LIBRARY points to libadbc_driver_flightsql.{so,dylib,dll}

Reproduction

In a Homebrew source-build formula environment on macOS with Python 3.13:

brew install --build-from-source ./Formula/d/dbt-mcp.rb

The build fails while preparing the adbc-driver-flightsql wheel.

Failure

The relevant error is:

ValueError: Must provide ADBC_FLIGHTSQL_LIBRARY

This comes from the adbc-driver-flightsql build step, which expects an already-built Flight SQL shared library to exist before pip install runs.

Why this is a blocker

This prevents dbt-mcp from being packaged in source-only environments unless they also independently provide the native Flight SQL driver library and wire the environment variable correctly.

Possible fixes

Any of these would unblock source-based packaging:

1. Make the semantic-layer / Flight SQL dependency optional instead of unconditional in the base install.
2. Split the semantic-layer support behind an extra that downstream packagers can opt into.
3. Provide a supported source-build path for the native Flight SQL dependency chain in the published sdist/wheel workflow.
4. Document a stable packaging contract for the required native library path and supported provider packages.

If useful, I can also provide the exact Homebrew formula patch I was testing and the full failing log excerpt.

[jairus-m]

Hi @chenrui333 ! Thanks for opening this up and thanks for the community work you've been doing to get MCPs included into homebrew-core.

For the first two possible fixes:

1. Make the semantic-layer / Flight SQL dependency optional instead of unconditional in the base install.
2. Split the semantic-layer support behind an extra that downstream packagers can opt into.

These would entail implementation changes in our code and would also change the installation UX for users (explicit opt-into SL tools). While valid approaches, these present some real tradeoffs! For options 3 and 4, those may require upstream changes outside of this project (?).

However, the major piece of context is that currently, our docs guide users to install and/or run the dbt MCP flexibly via uvx. This is our primary mode of distribution and so far, we've not had any community ask for installation via homebrew.

So given the tradeoffs and how our users currently run/install dbt-mcp, supporting homebrew is not high-priority for us right now.