[Bug] AttributeError: 'Namespace' object has no attribute 'MACRO_DEBUGGING' #731
Comments
jelstongreen
added
bug
|
The only similar thing I have found is: dbt-labs/dbt-core#7312 |
jelstongreen
changed the title
|
Thanks for reporting @jelstongreen! Let me look into this one. I've seen this before when invoking dbt runner, but i can't remember what the fix was 🤔. |
|
@jelstongreen this typically happens when you have some nested macro evaluation hidden somewhere, because that triggers the full dbt jinja environment rendering. Do you happen to have any custom macros embedded in your profiles.yml, or non-standard path configuration overrides for your project or profiles paths? We should support env_var() but anything more than that might cause this behavior, and our path requirements are a bit stricter than dbt's. The API we're relying on for dbt adapter initialization does not use the full macro/project aware runtime config, so we can't run all of the flexible parsing stuff dbt normally provides. If you run |
|
We definitely have some non-standard path configurations as we have a multi-project repo with some upper directories re-used in multiple projects using model-paths. Something like: We also have macros in the project.yml like: And some use of Would that cause the issue maybe? |
|
@jelstongreen Let me see if I can repro. |
|
@jelstongreen we haven't been able to repro with the macros - we use env_var in our CI and @Jstein77 added some I'm not familiar enough with dbt core to know if multi-project model path resolution would trigger this issue. It might. We'll dig into this bit further and let you know what we come up with. If you feel ambitious, and if it's even possible, you might try removing the multi-path just for a local run and see if you can get the project info, but I suspect that'll break for other reasons. One thing you might try - if you're able to modify the code in the metricflow package, update our dbtRunner invocation to use If dbt parse works we might be able to provide an option to do a full parse on demand, and that'd at least give you a work-around (while also improving quality of life for addressing the "I forgot to run dbt parse after updating my YAML configs and now everything is broken" scenario). |
|
Hi all, just to jump on to the thread I have been able to reproduce the errors that @jelstongreen described, where dbt-metricflow is unable to reference any of the global flags when loading the profile. I believe it is directly related to our project structure where we have multiple dbt projects within the Result: Therefore I don't think it is do with the macros and relative paths that we have in our dbt_project.yml, but the structure of our project. Ideally we would like to be able to run the Also, modifying the metricflow package to run a parse instead of debug resulted in the same error messages. |
|
@MadyDaby ah, thank you for the investigation and update with repro cases. @Jstein77 I think this might resolve to the same issue as #643 in which case we should merge them, provide more detail on what we need for #643 (flags, basically), and have that open for contribution. If this is separate we can open this up - adding flags to the CLI for this stuff shouldn't be too hard today, it's more a question of where they belong and what the command structure itself should look like. |
Is this a new bug in metricflow?
Current Behavior
When running any
mfcommand I receive an error:If I comment out this section of code in the package I get a similar error for profiles:
Expected Behavior
Mf to work
Steps To Reproduce
11:00:25 Running with dbt=1.6.0
11:00:25 dbt version: 1.6.0
11:00:25 python version: 3.11.2
11:00:26 adapter type: databricks
11:00:26 adapter version: 1.6.1
mf list dimensions --metrics charged_consumptionRelevant log output
No response
Environment
Which database are you using?
other (mention it in "Additional Context")
Additional Context
Databricks
The text was updated successfully, but these errors were encountered: