Source
aniforprez•

From what I can tell, .env files – sometimes called environment variable definitions files – come from the twelve-factor app design, and specifically the config portion

Already wrong. Env files were not created from 12 factor. They were available for a long time before 12 factor was even a thing

And I don't understand why a TOML file has to replace env files. I've recently used TOML or YAML as a set of defaults that gets checked in that allows a developer to work locally and overriding each value with environment variables that are loaded and merged with the current configuration. This allows you to override very specific values in production or staging environments rather than having to write everything in a new file. It also allows each developer to override their specific values locally. This also creates transparency around what configuration keys are expected

6
alexisprince•

We have the exact same setup at my work as well. I personally love using TOML for configuration due to its clear nesting and comments and that it always maps to a dictionary (previously we were using json).

On top of that, we also load our configuration into a Pydantic settings model that lets us do further validation of the settings based on environment. It feels like a very smooth and intuitive workflow, while the amount of code needed to load configuration is pretty small.

1
aniforprez•

I personally really like dynaconf which is pretty flexible and has a lot of features like out-of-the-box support for Vault. But I've really liked pydantic too

2
cblegare•

If you ship your .env or toml files with your application, you are not respecting the 12 factors app principles.

The idea is to have your application be configurable from the outside (from the environment, hence environment variables). For example, you ship your application as a container image and run it in kubernetes, your configuration should come from the deployment definition, not the container image itself. It is OK to have configuration as toml, JSON, XML or whatnot files as long as it is an input from the environment.

6
paraffin•

For Python project configs I recommend ConfZ.

It already has toml support, and any dotenv project can be migrated to it.

I like it because you can explicitly define a hierarchy of config sources for mixed needs, it uses Pydantic models so that not everything is a string, and you get all the boilerplate of config out of the way.

2
osusc•

You can do this with pydantic BaseSettings as well using the config class on the model.

2
paraffin•

I wasn’t aware! Looks decent, but honestly I think the ConfZ setup is a little more straightforward as a purpose built solution. Might give that a try when I don’t have as much freedom to toss in packages though.

Also, does it support toml out of the box? Doesn’t look like it from that page.

1
osusc•

You're right you would have to write a custom source for toml. ConfZ seems useful if you have a lot of complicated deps. Also the lazy loading is something I've always wanted from pydantic settings.

2
Jerscovad•

Tried out toml since I found out it’s built-in with 3.11 and I wouldn’t be surprised if there comes a standard based on it in the future. It’s quick and easy and quite handy for storing all types of config and env vars.

2
Glowing_Shadows•

yup its a great way to store env variables and also plugin configs

1
RaiseRuntimeError•

How do we get this to happen? I would rather use toml files over .env in my projects.

1
Simaryp•

How is the toml file used internally? A cool thing about dotenv is that you can import the env file with overwrite set to False. So you can implement a hierachy: system environment before .env before defaults. So one can use the library with sane dedaults or write an .env file or can inject the envvars into a docker container etc. Additionally since you use them via os.getenv you don't have to hand them over between different modules. How does that work with toml?

1