feat: allow env function for config.toml to have a default value

[pathob]

What kind of change does this PR introduce?

Feature

What is the current behavior?

Currently, the env function used in the config.toml file only supports reading environment variables without any fallback to a default value if the environment variable is not set:

secret_key = "env(SECRET_KEY)"

What is the new behavior?

The env function used in the config.toml file now supports default values for environment variables using this syntax:

secret_key = "env(SECRET_KEY, my_default_secret)"

Additional context

I need this functionality to implement dynamic environments while still being able to have hard-coded values in the config.toml file.

This feature was already wished by another user as I saw here: #1325 (comment)

[coveralls]

Pull Request Test Coverage Report for Build 17042942311

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 5 unchanged lines in 1 file lost coverage.
• Overall coverage decreased (-0.03%) to 54.691%

---

Files with Coverage Reduction	New Missed Lines	%
internal/gen/keys/keys.go	5	12.9%

Totals
Change from base Build 17040539148:	-0.03%
Covered Lines:	6167
Relevant Lines:	11276

---

💛 - Coveralls

[sweatybridge]

I need this functionality to implement dynamic environments while still being able to have hard-coded values in the config.toml file.

Have you considered using .env files to control this? For eg. you can declare default values in .env and commit it to git.

secret_key=my_default_secret

For environment specific overrides, add them either to .env.local or .env.prod file.

To use the prod override, you can set SUPABASE_ENV=prod before any CLI command, ie.

SUPABASE_ENV=prod supabase db push

I like your suggestion though, as it's more explicit than relying on the order of override like .env.local > .env.

[pathob]

Hi @sweatybridge

Have you considered using .env files to control this? For eg. you can declare default values in .env and commit it to git.

Not yet, but from this unmerged PR #3741 I assume that environment variables take precedence over .env files so yes, that would be a workaround to achieve the default value.

For environment specific overrides, add them either to .env.local or .env.prod file.

To use the prod override, you can set SUPABASE_ENV=prod before any CLI command, ie.

SUPABASE_ENV=prod supabase db push

Thank you for the hint, but with this approach I cannot really implement dynamic environments.

I like your suggestion though, as it's more explicit than relying on the order of override like .env.local > .env.

Great, I hope you consider it for merging, because I also find it more clean in cases like mine. :)

[sweatybridge]

but with this approach I cannot really implement dynamic environments.

Could you elaborate on what you mean by dynamic environments?

[sweatybridge]

Can we spell out what this means in terms of

1. string escaping for ", ', and \ in default value
2. how would user specify leading and trailing spaces in the default value
3. should we differentiate "true" and true