Config Tuples - Use config tuples on Distillery 2.0 releases

Your Libraries & OS Mentoring Libraries
, ,
1

Hi!

I’ve just released the first version of ConfigTuples, a Distillery’s 2.0 config provider to read what I call configuration tuples.

  • What are configuration tuples?
    This is the way I call the tuples that some libraries accept (and some libraries transform to normal configuration, like deferred_config) and some people in the community likes, this are the {:system, name} tuples and their family.

  • Why?
    If the library don’t support this kind of tuples you can’t easily set them up . Because I think this way of configuration for dynamic variables that come from the system environment is the most elegant way.

  • What tuples are supported?
    In the version 0.1.0 the supported tuples are: {:system, env_name}, {:system, env_name, default}, {:integer, value}, {:atom, value}, {:boolean, value}, this last three the value can be another config tuple, so for example you can read an integer from the environment system :smile:

I’m open to all your comments and thoughts, and they are more than welcome!

I hope you find at least interesting!
Cheers!

4 Likes
2

Oh hey, this looks like a released version of my config wrapping hacks but much easier to use, this looks quite useful! :slight_smile:

1 Like
3

Here in our company we have one hacky thing with distillery’s hooks, but with the release of 2.0 @teamon mentioned the config providers and I couldn’t take it out of my mind. Now that I’m on holidays I had some time to check it and came with it :joy:

1 Like
4

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.

2 Likes
5

Hi! I have to investigate it, because I think that by default Distillery don’t load your modules, I’ll take a look and let you know :slight_smile:

1 Like
6

I just released version 0.2.0 (And it’s a breaking one)!

This version simplifies the way to define the tuples, in the 0.1.0 there were many types of tuples, which could be confusing, in this version all are :system tuples, with optional parameters!

For example, what previously was {:integer, {:system, "PORT", "3306"}} now is {:system, "PORT", type: :integer, default: 3306}

This way the tuples are more simple, more explicit on what is going on, and allows the library to add more options in the future!

The supported types are :string (the default type), :integer, :atom and :boolean.

Check the README for more examples!

1 Like
7

Released version 0.2.1.

This version adds the transform option which is a {Module, :method} value that specify a method to be applied to the final value (after default and type applied):

{:system, "ENV", transform: {MyApp.Parser, :parse}}

Ping to @axelson that asked about it :smile:

2 Likes
8

Very neat, thanks!

1 Like
9

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 :smile:

3 Likes
10

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.

3 Likes
11

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 :smile:

3 Likes
12

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. :slight_smile:

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 :+1: or a :-1: 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. :+1: Thanks for replying!

3 Likes