dbt init should be able to create a project in the current directory

[tconbeer]

Feature

dbt_init should be able to create a project in the current directory

Feature description

Sometimes its's helpful to create a new dbt project in the current directory, rather than in a new directory. One example is when using dbt with pipenv. Ideally this sequence of commands would install dbt from scratch in a virtual environment, and then create a dbt project in that same directory:

> mkdir dbt\my-dbt-project
> cd my-dbt-project
> pipenv install dbt
> pipenv run dbt init

If dbt needs a project name, it could take it from the path or take a different argument to override the default "create a directory" behavior
> pipenv run dbt init my-dbt-project --current-directory

Who will this benefit?

People creating a new dbt project who plan on collaborating and require specific dbt versions to be installed across multiple machines.

[drewbanin]

this is a reasonable idea, but I don't think it's something we're going to prioritize any time soon. Closing, but we can re-open if anyone feels strongly

[thomashandorf]

this is bugging me for some time. It different from the semantics of other tools. E.g. 'git init' . It would be event great if it would ask in the first step to take the current directory or a subdirectory

[jtcohen6]

More recent issue proposing something similar: #4141

I'm not strictly opposed, if lots of folks want this

[thomashandorf]

Great to hear. I often have the workflow: create repo on github, clone repo to local, try to init dbt - damn ;)

[schlich]

I think this should be supported in the CLI. The current workaround is a pain if you'd like to use dbt's root-level configuration if you don't want to use the dbt cli to bootstrap the project. For example, I use poetry new to bootstrap my python projects and it makes much more sense to handle the installation of dbt first with poetry and configure the dbt config second. I shouldn't have to need mv for what others have mentioned is a basic cli option in many tools (git was mentioned, but also see poetry init vs poetry new).

[emilyriederer]

Upvoting this for the same use case as @schlich . I've been experimenting with switching to poetry for virtual environment management with dbt. Currently, it feels a bit clumsy to need the last two lines in:

poetry init
poetry add dbt-core
poetry add dbt-duckdb
dbt init 
cp -r dbt_demo/* .
rm -rf dbt_demo

[schlich]

@emilyriederer i'd still like to see first class support for this feature (particularly I think there are some details around getting the name of the profiles/paths right that need to be considered) but just as an FYI your workaround can be shortened to one line instead of two by using mv instead of cp 🙂 (edit: i guess you'd still have the empty directory sitting there, but it would at least avoid getting picked up by git).

[matthias-fbi]

Any updates on this?

I create a folder with an .venv inside, install dbt + connector and then try to run dbt init -> "A project called test_dbt already exists here"

But I need a .venv first to run dbt init in the first place but then can't run dbt init because of that .... ?!

[pxlhuntr]

@matthias-fbi That's exactly what brought me here! +1 for this, I thought I was crazy but glad to see I'm not alone in this.

[troflog]

I totally agree. I want to use:
uv init dbt-project
uv pip install dbt
dbt -c init
Then dbt init should use dbt-project as the folder. Here -c means current folder.

[zheacker]

Adding to this chorus, I'm also using uv and I'm trying to roll dlt, dbt, and dagster into a single project, and it would be a bit easier if this was supported.

[gdubya]

@zheacker ditto!