if a package name shadows internal context members, terrible things happen

[beckjake]

Describe the bug

If you run dbt compile, dbt run, you may get a message like this back:

Encountered an error:
'function' object has no attribute 'update' 

I think we can all agree that this is a very bad error message!

Steps To Reproduce

1. Name your project the same as any built-in default dbt function source, ref, log, ...
2. dbt compile

Various built-in context members might result in similar messages with function replaced by another type (also bad) or even silently corrupt dbt internal behavior (much worse)

Expected behavior

A clear and concise description of what you expected to happen.

I expect dbt to give me a good error message. Something like package names may not shadow builtin context members: "log" is not a valid value for package name is probably fine. This will be annoying when we add new things to contexts and users upgrade, but basically nothing will be as annoying as the current behavior.

Screenshots and log output

There's a big long stack trace in the debug log that points to the culprit (see Additional context for more on that), but nothing else useful.

System information

Which database are you using dbt with?

• postgres
• redshift
• bigquery
• snowflake
• other (specify: Any!)

The output of dbt --version:
Any >= 0.13.0

The operating system you're using:
Any

The output of python --version:
Any

Additional context

Some thoughts on fixing this:

• this error comes up in dbt.context.common._add_macro_map via _add_macros
• Any fix for this has to handle dependencies as well as the root project
• The current structure of modify_generated_context, which is what calls _add_macros, and generate_model (which calls modify_generated_context) make this not very straightforward, as we'll also want to explicitly blacklist the following keywords that aren't in the context yet at _add_macros time: write, render, var, context, this, pre_hooks, post_hooks, sql.
• Maybe we should generate a reserved keywords list somewhere else in dbt and use that. If we did that, we could spit this information out before doing context generation, which means we could do it during dbt debug/dbt ls/similar as well, which seems like a big upside.