Specify: Comfortable, Explicit, Multi-Layered Configuration Specifications - v0.7

Took a bit to read it, looks like a fantastic start!

So a few starter questions:

1. You can make arbitrary configuration loaders and handlers?

2. What about one that pulls from a database on some kind of update message so it updates the configurations in real time, is there a way to tell something like a gen_server built on this to accept this new configuration (say like changing the pool size in a database pool)?

3. How do you differentiate between the different stages of configurations? I.E. Compile-time, Load-Time, and Run-Time (dynamic)?

Yes . The Confy.Provider protocol can be implemented by anything you want.

Currently, not. I am planning to, in a way similar to what Vapor does, offer the possibility to spin up a background ‘configuration change watcher’ process that will trigger a message when the configuration changes at runtime. (Unfortunately for most providers this will require polling).

The GenServer could then decide to switch over to the new configuration, stop and start a new version of itself with the new configuration, or potentially even recompile a module if, for optimization reasons, the compilation process itself is affected by the configuration.

Confy treats them in the same way. Configuration is only ever loaded when YourConfigModule.load(options \\ []) is called. At that time, Confy will look through the sources that you have configured, and for every field, decide which source has the highest priority.

So if you have the following configuration:

defmodule MyRepo do
  import Confy
  defconfig sources: [Confy.Providers.MixEnv, Confy.Providers.Process] do
    field :endpoint, :string, default: "localhost"
    field :port, :integer, default: 8086
  end
end

then when calling MyRepo.load(options) it will:

• Take the default values of :endpoint and :port
• Possibly override them by a value set in the Application configuration.
• Possibly override them by a value set in the current process’ process dictionary.
• Possibly override them by a value set in the overrides: key of the options passed to MyRepo.load.

The idea is that you call YourConfigModule.load once (or infrequently) and keep the struct it returns around in e.g. your GenServer state.This means that parsing of individual config fields has to be done only once, and that you end up with an explicit representation of the configuration. Also, because you end up with ‘just’ a struct, the logic that uses this configuration can be completely stateless and might be easier to test.

I’d require the provider to handle that. For PostgreSQL for example you can LISTEN in it to get updates pushed for example.

The GenServer could then decide to switch over to the new configuration, stop and start a new version of itself with the new configuration, or potentially even recompile a module if, for optimization reasons, the compilation process itself is affected by the configuration.

The fact the OTP runtime doesn’t already have something that sends an update message to registered receivers when an application environment value changes is still a bit astounding to me… ^.^;

That’s a good idea. The protocol could definitely be extended by such a function(which could be opt-in, falling back to longpolling) .

Today I managed to put some more work in. Important changes for v0.3.0 are:

• New load_explicit that takes first a list of explicit values you want to provide (and the second, optional, argument is the list of options).
• The :overrides key has been renamed to :explicit_values because it more clearly shows its purpose in my opinion.
• Lots of tests have been written, and a couple of bugs were ironed out.

I currently envision two use-cases for this library:

1. Parsing configuration that is to be used for a GenServer (or similar process), by calling MySettings.load() at process initialization time.
2. Parsing of the options passed to use (and similar macros or functions), by calling MySettings.load_explicit(options).

In both of these cases, the main advantage of using Confy is the explicitness:

• you (the code maintainer) know what fields exist
• you (the code maintainer) know what types these fields will be
• consumers (that call your code) have documentation to find out what options can be passed, and see readable compile-time (or start-up-time) errors when improper things are passed.

Starting today, Confy has been renamed to Specify to be more clear in the main focus of the library, which is to make fields and field-types explicit, regardless of whether we are talking about app-wide configuration, user-created settings or single-function-call options.

Specify v.0.4.0 has been released, which replaces Confy v.0.3.0.

Also, what is better than a beautiful library? A beautiful library that has its own logo!

Ooo nice!

More tests and documentation has been written; version 0.4.2 has been released!

The library is inching towards a first stable release. There are still features that might be worthwhile to add, but the current core interface is starting to come together nicely.

Version 0.6 has been released!

Since the last update on the forum, the following improvements have been made:

• 0.5 - Adds the nonnegative_integer , positive_integer , nonnegative_float , positive_float and timeout builtin parsers.
• 0.6 - Adds the mfa and function builtin parsers.

I have one question to the community at large, which is about parsers like the function one. Currently there is no way to restrict a field expecting a function to a particular arity. What would be a good API for this?

I am thinking about two possibilities (but maybe there is a third as well):

• field(field_name, {:function, arity}, default: some_val)
• field(field_name, function(arity), default: some_val)

Currently, we already have {:list, :element_parser} (e.g. {:list, :integer}). It would be nice to keep a similar format, but I am not entirely convinced on the former format’s structure.

As for the roadmap: Currently the only thing that I’d consider blocking before v 1.0 would be the possibility to nest specifications. (And besides this resolving above issue, I guess).

Version 0.7 has been released!

This version adds:

• The possibility to make configuration source optional, which is rather nice because Specify warns when you do not fill in any fields in a particular configuration source. In certain cases it makes sense that a particular configuration source only exist some of the time (like setting optional system environment variables), which would make the warnings unneccesarily noisy.
• To make it easier to specify the default sources in e.g. the Mix.Config/Elixir.Config files where no dependencies (and thus not Specify either) are loaded yet, it now is possible to pass a source that you want to configure as {SourceModule, %{some: field, some_other: field}} which will be turned into a %SourceModule{some: field, some_other: field} struct on startup. A module/function/argument-syntax now is also provided, for even more flexibility.