Make dbt-core an optional dependency so edr can run against dbt v2 without a second dbt

[dobsontom]

Is your feature request related to a problem? Please describe.

elementary-data declares dbt-core<3.0.0,>=1.8 as a hard dependency, and every adapter extra pulls a 1.x adapter that depends on it too. Installed alongside dbt==2.0.1 (the Fusion engine), dbt-core wins the install: both ship a dbt console script and a dbt Python package, and dbt --version afterwards reports 1.12.4. Every dbt run in that environment silently drops to dbt 1.x.

The CLI imports dbt-core in one place, from dbt.cli.main import dbtRunner, dbtRunnerResult in clients/dbt/api_dbt_runner.py, which is the dbt 1.x runner. Dbt2Runner from #2333 drives Fusion over a subprocess and doesn't need it, and edr never opens a warehouse connection of its own, so under dbt v2 neither dbt-core nor a Python adapter is doing anything.

Describe the solution you'd like

Move dbt-core out of the base dependencies into an extra, the way the adapters already are, so pip install elementary-data on its own works against a Fusion binary found through DBT_FUSION_PATH. #2333 already detects "no dbt-core, Fusion binary present", so the runtime side exists and this is packaging.

Describe alternatives you've considered

Keeping edr in its own virtualenv, separate from the dbt project's. That's what we've done, though it means a second lockfile and a second dependabot entry for one CLI.

Additional context

elementary-data 0.26.0, dbt 2.0.1 on Snowflake, Python 3.14.

[rbmuller]

I ran into this too. Looking at the code, the runtime side seems to already be there — the blocker looks like packaging alone.

factory.py imports APIDbtRunner lazily, Dbt2Runner and SubprocessDbtRunner shell out to the binary, and get_dbt_core_version() already returns None when the package is absent. Across elementary/, the only module-level from dbt import is api_dbt_runner.py — the other hits are Jinja macros in .sql. So dbt-core appears to be needed only by the API runner, which is the one path a Fusion user never takes.

That would make the change roughly:

• move dbt-core = ">=1.8,<3.0.0" out of [tool.poetry.dependencies] into an optional extra
• leave the adapter extras alone, since each already pulls dbt-core 1.x transitively
• add one clear error when neither dbt-core nor a dbt 2 binary is found, since today that path ends in a confusing subprocess failure

The part that's yours to decide: pip install elementary-data currently gives a working 1.x setup, and this would end that. Acceptable in a minor, or would you rather stage it?

Happy to put up the PR if you're open to it.

[jefersonmsantos]

This is already addressed in an open PR — linking here so others don't duplicate the work.

Code: #2360 — Remove the CLI's hard dbt-core dependency (dbt v2 ships as dbt/dbt-oss) (CORE-1477, follow-up to #2333)

Docs: #2361 — two-path CLI install (dbt v2 vs dbt Core 1.x with dbt1-* extras)

#2360 makes dbt-core optional: plain pip install elementary-data no longer pulls in dbt-core 1.x, so it can coexist with pip install dbt / Fusion in the same environment. dbt-core 1.x still comes in via the existing warehouse extras (now also documented as dbt1-<warehouse>), with dbt-core pinned <2.0 in those extras.

CI on #2360 is green across the warehouse matrix and fusion/dbt2 targets. Happy to help review or land small follow-ups (e.g. removing the obsolete pip uninstall dbt-core step in Fusion CI once packaging lands) rather than open a competing PR.

@haritamar — if you agree this closes this issue, adding Closes #2354 to the #2360 description would auto-close on merge.