-
Notifications
You must be signed in to change notification settings - Fork 967
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document dbtRunner (programmatic invocation) #3118
Conversation
✅ Deploy Preview for docs-getdbt-com ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
title: "Programmatic invocations" | ||
--- | ||
|
||
In v1.5, dbt-core added support for programmatic invocations. The intent of this entry point is provide **exact parity** with CLI functionality, callable from within a Python script or application. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something like this?
The intent of this entry point is to expose the existing dbt CLI via a Python entrypoint, so it is callable from a Python script or application.
|
||
In v1.5, dbt-core added support for programmatic invocations. The intent of this entry point is provide **exact parity** with CLI functionality, callable from within a Python script or application. | ||
|
||
The main entry point is a `dbtRunner` class that wraps around `dbt-core`'s CLI, and allows you to "invoke" CLI commands as Python methods. Each command returns a `dbtRunnerResult` object, which has three attributes: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be the opposite? The CLI technically wraps the Click runner that dbtRunner
depends on.
|
||
### `dbtRunnerResult` and exit codes | ||
|
||
There is a 1:1 correspondence between [CLI exit codes](reference/exit-codes) and the `dbtRunnerResult` returned by a programmatic invocation: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's put this in a table?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea of tabling it up here as well!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's copy the same table here; most people aren't going to click on links.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait, it's a different table – here the columns should be: scenario
, success
, exit_code
, result
, exception
.
2. At least one handled error (e.g. test failure, model build error): `success=False`, exit code `1`, `result` populated (based on the command), `exception` empty. | ||
3. Unhandled error: `success=False`, exit code `2`, `exception` populated with top-level error, `result` empty because the invocation did not gracefully complete and return results. | ||
|
||
### Caveats |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be SLA or similar?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As in - our SLA (set of guarantees) to end users, in terms of stability of the interface across future versions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, correct.
@@ -190,4 +190,10 @@ The `EVENT_HISTORY` object has been deprecated and removed in dbt Core v1.4+ | |||
|
|||
Older versions of `dbt-core` made available a full history of events fired during an invocation, in the form of an `EVENT_HISTORY` object. | |||
|
|||
The Python interface into events is significantly less mature than the structured logging interface. For all use cases, we recommend parsing JSON-formatted logs. | |||
<VersionBlock firstVersion="1.5"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TIL, neat!
|
||
### Caveats | ||
| Scenario | CLI Exit Code | `success` | `result` | `exception` | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: numbers should be right-aligned using the |---:|
header.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TIL!
|
||
- The `results` objects returned by each command are liable to change. Some of these objects are already contracted, in part, because they overlap with [dbt artifacts](dbt-artifacts). | ||
From dbt Core v1.5 onward, we making an ongoing commitment to providing a Python entry point at functional parity with dbt-core's CLI. We reserve the right to change the underlying implementation used to achieve that goal. We expect that the current implementation will unlock real use cases, in the short & medium term, while we work on a set of stable, long-term interfaces that will ultimately replace it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this language, ty.
Pass in params as `**kwargs`, instead of passing in a list of CLI-style strings. At present, dbt will not do any validation or type coercion on your inputs. The subcommand must be specified, in a list, as the first positional argument. | ||
### Overriding parameters | ||
|
||
Pass in parameters as Pythonic `**kwargs`, instead of a list of CLI-style strings. At present, dbt will not do any validation or type coercion on your inputs. The subcommand must be specified, in a list, as the first positional argument. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: this is not Pythonic style, Python lets you do this as an escape hatch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Heh, good point. I'm just going to change this to Pass in parameters as keyword arguments
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly LGTM, couple nits.
@aranke Thanks for the re-review! Good nits, quickly fixed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most Python examples confirmed to work!
Suggestion with code fix for the lone exception.
Co-authored-by: Doug Beatty <44704949+dbeatty10@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Love having these example Python scripts!
What are you changing in this pull request and why?
I've scaled back my original ambitions from #2674 / #2693, given that we de-prioritized some docs improvements, in favor of bugs/regressions before the v1.5 release (more important!).
I think some human-written docs for now are more than sufficient. I need to add examples for the "advanced" usage patterns, and also add more caveats about what users should/shouldn't expect to remain stable in future versions.
Checklist
Other acceptance criteria
Adding new pages (delete if not applicable):
website/sidebars.js