[Feature] Accept None as a default in env_var

[dschneiderch]

Is this a new bug in dbt-core?

• I believe this is a new bug in dbt-core
• I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior

env_var does not recognize None or none as a default.
If the environment variable is not defined I see Parsing Error Env var required but not provided: '{ENV_VAR}'

I also tried env_var('NAMESPACE',none) | as_native and env_var('NAMESPACE','none') | as_native and env_var('NAMESPACE','')|as_native

Expected Behavior

{% macro namespaced(prefix)  -%}

    {%- set _namespace = env_var('NAMESPACE',none) %}
    {%- if _namespace is none %}

        {{ prefix }}

    {%- else -%}

        {{ prefix }}_{{ _namespace | trim }}

    {%- endif -%}

{%- endmacro %}

In the macro above I would like to set _namespace to none and check if _namespace is none.
I have another macro that uses var() and this works as expected.

Steps To Reproduce

Set up a macro that access an env_var that does not exist then call that macro from a model, for example as part of {{ config(alias=namespaced("MY_TABLE")) }}

Relevant log output

No response

Environment

- OS: macos 14.5 (intel)
- Python: Python 3.10.14
- dbt --version                            
Core:
  - installed: 1.8.4
  - latest:    1.8.4 - Up to date!

Plugins:
  - bigquery: 1.8.2 - Up to date!

Which database adapter are you using with dbt?

bigquery

Additional Context

No response

[dbeatty10]

Thanks for reaching out @dschneiderch !

I see what you are saying about var("something", none) and env_var("something", none) behaving differently when the relevant (environment) variable is undefined and how that is surprising and doesn't work for your use-case.

In the case of env_var, it looks like it was intentionally coded to have the behavior you observed here and here.

So I'm going to change this to a feature request for further consideration.

[kentkr]

@dbeatty10 do you have an inkling as to why this behavior might be intentional?

It's logical to think a user might not know an env var needs to be set. But the solution in #10629 can delineate between an env var that is not set vs set to None.

As for my use case this would be beneficial. We created a custom ref macro that handles custom schema names depending on the env. For dev the env var is set to None.

Our solution was to account for different types of none (none, 'none', 'None', '', ...) in the macro. Pretty simple but not desired.

Thanks!

[dbeatty10]

Thank you for that context -- helpful 🧠

@dbeatty10 do you have an inkling as to why this behavior might be intentional?

I don't know why it was intentional!

So we are in a Chesterton's fence scenario that will take some more research and conversations to learn more. But this isn't very high priority for us right now, so we haven't been able to dedicate the time towards it.