Using TOML for user-specified runtime config

I’m starting to work on my first real app and can’t quite understand the runtime configuration story. I would like to use a TOML file to hold the configuration data. My plan is to look for this config.toml file in the path $XDG_CONFIG_HOME/my_app/config.toml or perhaps even iterate through $XDG_CONFIG_DIRS appending /myapp/config.toml to each until one is found. If no file is found a default config will be included.

I would like to use the Toml library to parse the config but I’m not following the guidance on organizing the configuration from the docs. I’m also not clear on how one would access the config data later.

From here I gather I need a config/runtime.exs to fetch the configuration data. I assume this is where the code suggested in the Toml docs goes:

# config/runtime.exs

config_providers: [
  {Toml.Provider, [
    path: {:system, "XDG_CONFIG_DIR", "myapp.toml",
    transforms: [...]
  ]}
]

So let’s say I have something like this snippet of the example from the Toml docs:

# This is an example of something that would be ignored
title = "My config file"

# We're expecting something like this:
[myapp]
key = "value"

How do I later access myapp.key to use “value”?

I’m wondering if it’s Applicationg.get_env/3?

You can also use something like Vapor.

1 Like

@stevensonmt, I believe you’ll want to look into Config.Provider. It’s your mix.exs file you’ll be adding that configuration to.

Thanks that makes sense. But then what goes into the config/runtime.exs file? And am I correct that Application.get_env and the like are how to retrieve the configuration data?

@cmo thanks! Vapor looks very straightforward.

If you’re using the Toml config provider because you don’t want to use runtime.exs, then don’t use runtime.exs. They’re two different sources of config. One does not load the other. You could use both if you want to confuse yourself or if you want the runtime.exs stuff ever so slightly further out of reach than the config.toml.

And yes, config is retrieved with Application.get_env and friends.

2 Likes

Excellent. Thanks for your help. I’m trying not to assume end users would be familiar with Elixir but would be with TOML.

1 Like

Just a hint for anyone stumbling on this thread later, Vapor.load!(config_providers) does not put the configuration keys into the application env. I’m guessing it just parses and stores in memory? IDK, but after loading the providers you have to call Application.put_env(:your_application, :key, value) for each configuration setting of interest. If I’m doing this wrong I hope someone can correct me, but without that step my application env is just an empty keyword list.

It wasn’t explicitly stated but I assumed before you were using GitHub - bitwalker/toml-elixir: An implementation of TOML for Elixir projects, compliant with the latest specification.

If using Vapor, then yes you’ll need to call Application.put_env/4 yourself, if you’re planning to access those values via the application environment.

Vapor is using toml-elixir as a dependency. Before Vapor was mentioned on this thread I had intended to use it directly, but with Vapor I can allow multiple user-specified config formats.