Repository navigation
Make dbt-core an optional dependency so edr can run against dbt v2 without a second dbt #2354
Description
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.
Activity
rbmuller commentedon Sep 23, 2026
I ran into this too. Looking at the code, the runtime side seems to already be there — the blocker looks like packaging alone.
factory.pyimportsAPIDbtRunnerlazily,Dbt2RunnerandSubprocessDbtRunnershell out to the binary, andget_dbt_core_version()already returnsNonewhen the package is absent. Acrosselementary/, the only module-levelfrom dbtimport isapi_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:
dbt-core = ">=1.8,<3.0.0"out of[tool.poetry.dependencies]into an optional extraThe part that's yours to decide:
pip install elementary-datacurrently 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 commentedon Sep 27, 2026
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-coreoptional: plainpip install elementary-datano longer pulls in dbt-core 1.x, so it can coexist withpip install dbt/ Fusion in the same environment. dbt-core 1.x still comes in via the existing warehouse extras (now also documented asdbt1-<warehouse>), withdbt-corepinned<2.0in 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-corestep in Fusion CI once packaging lands) rather than open a competing PR.@haritamar — if you agree this closes this issue, adding
Closes #2354to the #2360 description would auto-close on merge.