Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[BLOCKING] Define what values end up in the rendering context, and where #1255
Currently, rendering in dbt is pretty ad-hoc. We should define what is rendered, where, and with what context very explicitly. It might end up being complex or layered, but at least having it defined and somewhat consistent should be possible.
The status quo:
We should define some rules for these things and formally document them. I think a good start would be:
@drewbanin any feedback on other variables you'd expect to be available in
Who will this benefit?
developers, end users, anyone who wants to understand what dbt is doing with their config.
Yeah! A great example is: should vars defined or overridden in dbt_project.yml's
I would prefer to only support cli-supplied
@beckjake strong agree that we should document these contexts more clearly. I'm all for documenting the current state of things (even if it's dumb, unintuitive) but I don't think we should actually mutate any contexts right now.
If anything, I want to bias in favor of restricting the available context as much as possible (for now). We ran into this with
When we do document this, I want to document only the set of context variables that we're sure we can support well going forwards. That might mean things like not documenting
I'm very on board with documenting the craziness, but let's produce two sorts of descriptions:
The differences between the two will point out where things are inconsistent/poorly defined. We should then queue up work to resolve these inconsistencies. @beckjake if you can do the first part, I can do the second part :)
Without checking, pretty sure that if you've defined
But I agree, that's why I think we should only support cli-defined
I'll do my best to document the status quo over the next few days. As you indicate, var scoping is arcane at best!
changed the title
Define what values end up in the rendering context, and where
Feb 6, 2019
I just kicked this into Wilt Chamberlain. We should do it, but I just need to find some time to write everything down (and figure out a sensible format, since it's a lot of data!)
Would it be reasonable to unit test the context? I'm thinking we could write a contract, then use that contract to generate (even manually!) the docs. Otherwise, it's kind of a mess to keep everything straight everywhere.
This doesn't really handle things like the difference in
Yes, I think that's a fantastic idea!