[CT-1357] [Feature] DBT_PROJECT_DIR env var

[jtcohen6]

Is this your first time submitting a feature request?

• I have read the expectations for open source contributors
• I have searched the existing issues, and I could not find an existing issue for this feature
• I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

Describe the feature

First proposed in #5411. Not included in initial implementation from #5717

It should be possible to set the --project-dir CLI flag via env var instead: DBT_PROJECT_DIR

It's very easy to do this using the new CLI framework:

dbt-core/core/dbt/cli/params.py

Lines 220 to 234 in 73aebd8

	profiles_dir = click.option(
	"--profiles-dir",
	envvar="DBT_PROFILES_DIR",
	help="Which directory to look in for the profiles.yml file. If not set, dbt will look in the current working directory first, then HOME/.dbt/",
	default=default_profiles_dir(),
	type=click.Path(exists=True),
	)
	project_dir = click.option(
	"--project-dir",
	envvar=None,
	help="Which directory to look in for the dbt_project.yml file. Default is the current working directory and its parents.",
	default=default_project_dir(),
	type=click.Path(exists=True),
	)

It's a bit trickier for the old framework. See prior art from --profiles-dir:

dbt-core/core/dbt/main.py

Lines 1189 to 1201 in 73aebd8

	# profiles_dir is set before subcommands and after, so normalize
	if hasattr(parsed, "sub_profiles_dir"):
	if parsed.sub_profiles_dir is not None:
	parsed.profiles_dir = parsed.sub_profiles_dir
	delattr(parsed, "sub_profiles_dir")
	if hasattr(parsed, "profiles_dir"):
	if parsed.profiles_dir is None:
	parsed.profiles_dir = flags.PROFILES_DIR
	else:
	parsed.profiles_dir = os.path.abspath(parsed.profiles_dir)
	# needs to be set before the other flags, because it's needed to
	# read the profile that contains them
	flags.PROFILES_DIR = parsed.profiles_dir

We could consider waiting until we've cut over to the new CLI. (planned for v1.4 or v1.5)

Describe alternatives you've considered

Not doing this. It's a convenience (and consistency) thing. Given some recent comments on #5411, it sounds like this would help some people

Who will this benefit?

People who want to deploy dbt projects nested in subdirectories of larger repos, and want to set an env var once, rather than passing the --project-dir flag into every command

Are you interested in contributing this feature?

I think this could be a good second issue for a motivated community contributor!

Anything else?

No response

[dbeatty10]

It's very easy to do this using the new CLI framework:

Yeah! Hip, hip, hooray for the new CLI framework! Nothing better than a one-liner 💪

We could consider waiting until we've cut over to the new CLI. (planned for v1.4 or v1.5)

Agreed that this would be a good second issue for a motivated community contributor. I would affirm the option to wait until we've cut over to the new CLI If such a person doesn't emerge.

[aaronsteers]

Hi, @dbeatty10, @jtcohen6 - is it correct that it's not possible to use the extension today if dbt_project.yml is not in the root directory?

I've tried numerous workarounds with no luck as of yet. Then I found this issue. 😄

Thanks!

[dbeatty10]

Yep, that sounds right @aaronsteers

Let's say you have an environment variable named DBT_PROJECT_DIR.

Then here's a couple options using zsh/bash:

1. dbt build --project-dir $DBT_PROJECT_DIR
2. (cd $DBT_PROJECT_DIR && dbt build)

Once this issue is resolved and included in a release, then you'd be able to do the following, no matter the current working directory:

dbt build

[leo-schick]

@dbeatty10 @jtcohen6 I created a PR for this. Can someone do a review on it?