Advice how to go about library configuration from Elixir 1.9 and on?

There’s this approach, making the user explicitly pass init options.

https://github.com/spandex-project/spandex_datadog

I don’t understand what you mean about the 1.9 release though. It didn’t remove configuration, it just replaced Mix.Config with Config, and stopped generating a config folder for new projects (because libraries rarely need their own configuration). Those libraries still want to read configuration from the user though, so eg the phoenix generator will keep creating a config folder.

For compile time configuration, Config is still your best bet.

No, I don’t want compile-time configuration only – sorry, I was unclear on that point. I’d like the users of the library to be able to modify, say, sqlite command timeouts dynamically, at runtime.

I could use Config of course but IMO it seems clearer to me to just have hardcoded defaults that the user can override at the init step. I am open to suggestions, haven’t written an Elixir library before and can use all feedback and advice.

I mean this: Library guidelines — Elixir v1.20.2 (from the Elixir 1.9 announcement thread).

Ah, cool, I hadn’t seen that, thanks!

Then the link I posted should be relevant, since it is pretty much what the guidelines refer to here

In case you need to configure a process, the options should be passed when starting that process.

Having an init step like phoenix/ecto have also makes sense.

So given the 3 options above, what would you go for?

2 or 3 depending on what type of configuration we’re talking about. It’s pretty awkward to carry all options around to pass to every command, but some options only make sense when calling commands. For example, Redix has a timeout when calling redis commands, that option is not global, you pass it to Redix.command. But connection timeout is not per command, so it is passed when you start the process (also not strictly global, to be fair, it’s just per process).

Realistically you might have some of both.

I don’t think your options 1/2 really hit the nail for what the guidelines and removal of /config are meant to push people to.

If you have a library and no (configurable) processes are being started => accept config as parameters to functions. This could be supplying fresh config to each call, but also a config = MyApp.Config.validate(input) token to be passed around.

If you have processes being started, which need user configuration, let the user start those processes in their applications supervision tree and accept config as start arguments. Let your library functions receive a pid/registered name as argument to know which processes to call into (like e.g. GenServer.call). This isn’t really limited to a single process as well. What the user interacts with could just be a top level supervisor with many children.

If you have done the above things you can look into making configuration more convenient and less manual by additionally harnessing e.g. the application environment, process dictionary or having compile time config provided via macros (like e.g. Ecto.Repo does it). You could compile simpler API functions into some modules (MyModule.func(…) instead of Lib.func(MyModule, …)). This allows user to use those “limiting” configurations options if it fit’s their usage, but they can still go the more manual way and configure stuff via parameters/start arguments for more complex usecases.

Yep, that’s my option 3. The more I think of it the more it seems that I have to start from there because technically new processes or any OTP sauce isn’t necessary for using the library. In the end it’s just a NIF handle (bound to a Reference) that you will pass around.

Agreed, but that doesn’t cover the runtime configuration. So I plan to have something like Xqlite.Server.put_exec_timeout(pid, millis) that does a GenServer cast/call to a wrapper which keeps all configuration in its state.

And since the initial configuration can be supplied via OTP means then I think the Elixir’s configuration stack is superfluous in this case since both boot-time and runtime configuration is now covered.

If we worked together and I made that argument, would you agree with it?

This is what I am leaning towards as the final step of the configuration task for the library. Have (a) data structure capturing everything necessary to work with a single handle in the library – including handle-specific configuration like statement timeouts or batch sizes for records – and (b) have a GenServer wrapper for people who want to use the library with OTP, and then proceed to (c ) make convenience helpers to save some keystrokes or unite calls in one function instead of two or more.

Arguments passed to a process at startup is already runtime config. It’s done when starting the process and not at compile time. put_exec_timeout is rather “runtime updatable config”, which is imho another step up. Unless you have critical state to keep around I’d try to stay with a simple restart when changes need to be applied.

I did leave this out in my above text, but I’m not really a fan of using a process, which does only store config. If I want to keep config around I’d much rather put it in the application env and have it optimized for read concurrency than putting it in a process to have access to it serialized. My advice for configuring processes on startup is much rather meant to apply if you need processes to do the stuff your library provides.

For runtime configuration of your library you simply document the configuration options that the user will put in their releases.exs.

I can’t say I’ve seen this much in Elixir so I may be off base here but in Erlang we put defaults in the .app/.app.src file under the env key. You can do the same with the application configuration in your mix.exs.

But this is all assuming a use case that makes sense to have configuration read in from the environment. It depends on the application whether that makes sense or if it is a case better to have the user passing in a a set of configuration values when calling a function in your application.

Also your (2) and (3) aren’t mutually exclusive. If you have an application that must start servers you likely want to give the user a way to start them in their own supervision tree and have them pass in configuration to the start_link of whatever they are starting from your application.

(1) should never be used :). Not that the pdict should never be used, just almost never, but for configuration I think it is safe to say just “never”.