Error when setting up extension with var() calls in dbt_project.yml

[dwreeves]

Not sure if this is a bug / feature request, or if I am just misunderstanding something, so I am asking here.

Also, forgive me as I am setting up this for other users at my company and I am not familiar with VSCode or Typescript.

Issue

Our dbt setup is integrated in a larger system, and uses a shim of the dbt command that does a few things:

• pulls credentials from AWS Secrets Manager.
• adds extra options to some dbt subcommands, most notably for my purposes --vars

The first one is a nuisance but not a true blocker, since we can just have our analysts use ~/.dbt and have them use manually entered credentials and just rotate them when needed.

For the purposes of vscode-dbt-power-user, the thing I am struggling to work around though is the fact we use var() calls in our dbt_project.yml file. It's an open issue in dbt-core that var()s inside of dbt_project.yml cannot themselves be set with the vars: attribute in the yaml, so it necessitates passing in --vars in each CLI call.

The shimmed dbt command in our local setup works around this limitation of dbt, but there does not seem to be a way for us to hook into that so we are out of luck.

Two possible solutions

At least for my use case, one way around this would be to parameterize the dbt command in all invocations, not just dbt run and dbt build, which is the current setup. This way all dbt ... calls could contain --vars. (This wouldn't solve the AWS credentials thing, but it would solve the vars thing which is the bigger issue I have.)

Another solution would be to allow for altering the invocation of dbt itself. I see that the code executes python -c "CODE_STRING" where the code runs dbtRunner from the dbt Python package. If we could alter the CODE_STRING, this would make it feasible to do what we want. (This would solve both of my blockers.)

[anandgupta42]

@dwreeves #120 seems relevant to your problem.

[dwreeves]

Eh, I would argue not really. This overrides the Python executable, not the actual command invocation. The command executed is python -c "..." and this just changes which python is called. I could either hack around with it in a totally absurd way where I make it point to some bash script and grep it for the cmd actually passed in, or create a new venv with a custom bin/dbt, but both "solutions" would be pretty ridiculous. I think I'm looking to see if there is an appetite from the maintainers for a potential feature addition that would feel more typical.