-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Feature: contexts cleanup #2085
Conversation
982b59e
to
fda0202
Compare
fda0202
to
889cf77
Compare
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 just did a first pass here. I'd like to spend some more time functional testing this, but did want to get some initial comments on your radar!
Overall, wow, this is a heroic looking PR. Looking forward to getting this merged!
# project_profile_name is ignored, we just need it to appease mypy | ||
# (Profile.from_args uses it) | ||
# profile_name from the project | ||
partial = Project.partial_load(os.getcwd()) |
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.
👀 do we want os.getcwd()
here? Does running dbt from a subdir still work?
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.
Yeah. the relative directory handling stuff actually uses chdir
to go up the file tree before this is ever called, so the current working directory is in fact fine here.
) | ||
|
||
# get a new renderer using our target information and render the |
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 feels totally appropriate and sensible to me!
513bcfe
to
987cbc2
Compare
Rewrite/reorganize contexts - now they are objects that have a to_dict() - special decorators on properties/methods to indicate membership - reorganize contexts/ to remove many many import cycles Context behavior changes: - 'dbt_version' is alwways available - 'target' is available as long as the profile has been parsed - 'project_name' is available in: query headers, hooks, models, and macro execution Profiles/projects now render at load time - reading a profile or project file requires a ConfigRenderer - projects get an extra-fiddly special load for use during initial parsing - it returns the profile name and a function that, given a renderer, can return the rest of the Project - idea is: use the profile name to load the Profile, use that to build a ConfigRenderer that has a TargetContext, render the project with that - profiles.yml is rendered with the 'base' context - dbt_project.yml/schema.yml/packages.yml are rendered with the 'target' context: 'base' context + 'target' - docs are rendered with the docs context: 'target' context + the 'doc' function - query headers are rendered with the query header context: 'target' context + macros + 'project_name' - executed macros/models should have the same context as previously (query headers + adapter/model/etc related functions) Moved actual ref/source searching into the manifest Moved the rest of the parse utils into parser/manifest.py Made the ref/source resolvers defined in the provider context a bit more sane/well-defined Picked consistent-but-not-great names for all the various context generation functions Moved write_node into ParsedNode
Make slight tweaks to project initialization to support tests
987cbc2
to
148ef0d
Compare
Rebased to handle a merge conflict |
Fix comments Implement a TODO around duplicate macro names - added unit tests for it Implement a TODO around ref resolution
148ef0d
to
2e5fdbf
Compare
Per slack discussion, merging this. |
The `project_name` is not available in the `dbt_project.yml` context. 'project_name' is available in: query headers, hooks, models, and macro execution See: dbt-labs/dbt-core#2085
Fix #1503
Fix #1981 (you can still access it via
ref
, but you really shouldn't)Fix #1255
Rewrite/reorganize contexts
to_dict()
(but notdataclass
es, and notJsonSchemaMixin
s)dbt.context
package to remove/avoid most import cyclesHigh-level context behavior changes:
Profiles/projects now render with more complete contexts
ConfigRenderer
, which accepts a context dict as its argumentProfile
, use that to build aConfigRenderer
that has aTargetContext
, render the project with thatprofiles.yml
is rendered with the 'base' contextdbt_project.yml
/schema.yml
/packages.yml
are rendered with the 'target' context: 'base' context + 'target'Moved actual ref/source searching into the manifest
Moved the rest of the parse utils into parser/manifest.py
Made the ref/source resolvers defined in the provider context a bit more sane/well-defined
Picked consistent-but-not-great names for all the various context generation functions
Moved write_node into ParsedNode
I had to thread the ConfigRenderer all through the deps code because way down in there, it wants to read projects for metadata reasons. I'm not sure what the best way to fix that is and I don't want to do it in this PR, but deps definitely shouldn't do that.
I'd like to write some net-new tests, but here is an initial pass that shouldn't break much of anything (though adding everything to the context may in fact do so).