question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Env vars are case sensitive (overriding only uppercase params if written in uppercase) when merge_enabled=True

See original GitHub issue

Let’s say i have very simple yaml config with envs:

default:
  my_section:
    my_param: "default settings content"
development:
  my_section:
    my_param: "development settings content"

And i want to override my_param with env variable at some point. What’s proper env var name for such case? DYNACONF_MY_SECTION__MY_PARAM works if merge_enabled=False. However, if merge_enabled=True, DYNACONF_MY_SECTION__MY_PARAM will set my_section.MY_PARAM, not my_section.my_param. Easy reproducer:

import os
import dynaconf


os.environ["DYNACONF_MY_SECTION__MY_PARAM"] = "env var content"

settings = dynaconf.LazySettings(
	environments=True,
	env="development",
	settings_files=["settings.yaml"],
	merge_enabled=True,
)

print(settings.my_section.my_param)
print(settings.my_section.MY_PARAM)

Running the code returns the following output:

development settings content
env var content

setting merge_enabled=False and re-running the code returns expected output:

env var content
env var content

Documentation is kinda confusing about this behavior, so i’m not 100% sure it’s a bug: On the one hand, https://www.dynaconf.com/envvars/ examples are showing uppercase env vars are correctly recognized:

export DYNACONF_PERSON__IS_ADMIN=true
assert settings.person.is_admin is True

And it works like that with merge_enabled=False On the other - there’s the following line:

Also variable access is case insensitive for the first level key

And there’s https://www.dynaconf.com/configuration/#lowercase_read , so it looks like only the first level keys are designed to be case insensitive.

I’m using dynaconf 3.1.7, OS is macOS 12.2.1 if that matters.

Issue Analytics

  • State:closed
  • Created a year ago
  • Comments:7 (4 by maintainers)

github_iconTop GitHub Comments

1reaction
abalakhcommented, Apr 12, 2022

@rochacbruno yes, with lowercase everything works. That’s what i’m currently using as workaround.

0reactions
bartolootritcommented, Sep 5, 2022

@rochacbruno Yes. Thank you.

Read more comments on GitHub >

github_iconTop Results From Across the Web

The property definition in .env file is case sensitive. #9760
env is meant to set environment variables, so they should always be upper case.
Read more >
Correct Bash and shell script variable capitalization
Remember that variable names are case-sensitive; this convention avoids accidentally overriding environmental and internal variables.
Read more >
Is it just a convention or all environment variables have to be ...
Answer. There is a general consensus on how to write environment variables or shell variables which is all uppercase with underscores if needed ......
Read more >
86725 – Environment vars on windows: lowercase/uppercase
When a client chooses to override environment variable values when launching, we treat the variables as case insensitive on Windows. That is, if...
Read more >
os.environ forces variable names to upper case on Windows
The Windows functions that deal with environment variables are case-insensitive and case-preserving, like most Windows file systems.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found