Why not use environment variables directly?¶
There is a common pattern to read configurations in environment variable that look similar to the code below:
if os.environ.get("DEBUG", False): print(True) else: print(False)
But this code have some issues:
- If envvar
DEBUG=Falsethis code will print
os.environ.get("DEBUG", False)will return an string ‘False’ instead of a boolean False. And a non-empty string has a
- We can’t (dis|en)able debug with envvars
- If we want to use this configuration during development we need to define this envvar all the time. We can’t define this setting in a configuration file that will be used if DEBUG envvar is not defined.
No, prettyconf was designed to be framework agnostic, be it for the web or cli applications.
What is the difference between prettyconf and python-decouple?¶
There is no subtantial difference between both libraries.
highly inspired in
python-decouple and provides almost the same API.
The implementation of
prettyconf is more extensible and flexible to make
behaviour configurations easier.
You can use any of them. Both are good libraries and provides a similar set of features.
Why you created a library similar to python-decouple instead of use it?¶
I made some contributions for python-decouple previously, but I needed
to change its behaviour as described above and this change is backward
incompatible, so, it could break software that relies on the old behaviour.
Besides that it’s hard to make this change on
python-decouple due to
the way it’s implemented.
See the lookup order of configurations below
|Lookup Order||prettyconf||python-decouple (<3.0)||python-decouple (>=3.0)|
|3||*.cfg or *.ini||ENVVAR||settings.ini|
How does prettyconf compare to python-dotenv?¶
On the other hand, prettyconf does not populate the
because it is designed to discover configuration from diferent sources, the
environment being just one of them.