Released version 0.2.5!

I forgot to post updates since 0.2.1, so I’ll write all the changes since then:

0.2.2:

• Fix a bug when type: :boolean and default: false, it was being set to nil

0.2.3:

• Support for :literal option to bypass the replacement: {:system, :literal, {:system, "HOST"}} this will save in the configuration {:system, "HOST"}.

0.2.4:

• Support nesting maps and tuples.

0.2.5:

• Add a required parameter, that will make it to raise an error if the environment variable is not setted: {:system, "HOST", required: true}. In this version the required it’s opt-in, but in the 0.3 maybe it will be required by default and opt-out of the requeriment.
• Update README with trade offs section

Thanks @ericmj for the PRs for 0.2.3 and 0.2.4

May I ask what is the benefit of config tuples now that Distillery 2.0 supports runtime configuration?

Instead of:

config :foo, bar: {:system, "FOO_BAR"}

I can rather do:

config :foo, bar: System.get_env("FOO_BAR")

And the benefit of the latter is that it can be shared between compile and runtime. The config tuple only works inside a release.

Sure, thanks for asking!

One of the reasons that I had is that with the config provider Mix.Releases.Config.Providers.Elixir you needed one config file in rel/config/config.exs and then you would have config/prod.exs and that one. But I just tried copying config/prod.exs and it works, so that’s not really a reason. Basically I didn’t liked that you had two different files in different locations for production configuration.

So, the only reason left is the simplicity to do type casts, default values and transforming the value, which with the library it can be made with a simple interface.

It’s probably not a big reason, but I do really like to have the configuration files simple than with repeated code to transform the values (or having to create a helper module in all my projects to do that).

At last, when I want to test my app in a production-like environment (compile with MIX_ENV=prod), I want it to be as close as possible to the real production code, and that means using distillery to do the production release, so I don’t really face the problem of having a prod.exs file that don’t work without distillery.

But I admit that this are really personal preferences

As you said though, config/prod.exs no longer works for mix run with config tuples so you don’t have two files, but you don’t have the same functionality. There is nothing stoping you from doing the same with distillery config and having a single file.

Also, it is worth saying the reason distillery went with two config files (afaik) is to separate compile time from runtime config. But I don’t think this is a or a for any because you can run into issues in both approaches (and this is mostly on Elixir rather than those libs).

I can see however the convenience of the system API. Thanks for replying!

With a {:system, env_name} type tuple is it possible to specify a function that would transform the environment variable into the format that you want? Say if the environment variable was a full url but you want to separate the configs into a hostname and a path config.