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