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”.

Definitely pass the data around. If you use global configuration (e.g. application env) it means
you have less flexibility, you only have one configuration and so you can’t configure this
connection with X and that connection with Y.

As others have mentioned you likely have some startlink/init/connect/new/whatever function, so accept configuration there and pass it around to further calls. And if passing options is annoying to the users of the library they can (and often should) wrap the library with their own module.

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.