Conditional code based on config

Thank you!

Nothing wrong with runtime configuration. But that doesn’t help you if you’re doing meta programming at compile time.

Think of Ecto as a good example. Although all the Repo code lives in Ecto, you are required to create your own MyApp.Repo module and use Ecto.Repo in it with the appropriate configuration. Then the consumer of your code calls the API in MyApp.Repo, not Ecto.Repo. Thats the pattern to follow for your use case I think.

Happy to provide a few pointers on implementing this approach if you get stuck - here or just DM me.

I had a feeling that something like this would be the correct option. Otherwise the config is going to extremely unwieldy and redundant. I’m just not quite sure the right approach since coming from Ruby typically we’re able to just change everything at runtime (), exactly the kind of thing I’m learning Elixir to get away from…

I’m thinking I need to add some sort of boilerplate module that the client app can use in their own module, overriding the defaults somehow without actually changing how the original module is compiled. Does that sound generally like the right track to investigate?

The lib I’m working on is open source, and the current code I’m working on is here, if you’re curious.

To explain additionally why conditional compilation in a dependency isn’t a good idea I should point out that the dependency could be used my multiple different consuming libraries in the same runtime environment and therefore unpredictable behaviour would ensue.

The common pattern in Elixir to handle this kind of situation is to introduce a new module into the current project and then use the code from the dependency so you can create a relationship. This is what I do heavily in the ex_cldr libs for pretty much the same reason you have - conditional compilation of library code based upon configuration in consumer code.

Ah, I see. Compilation order is dependencies first, then the current project. Where current project is the one that has mix.exs in it when you did mix.compile. Dependencies are compiled first and they do not create a transitive association with the “current” project. Understandably so - libraries aren’t built to make assumptions about the projects that use them.

TLDR; A dependency depending on the consumer of the dependency isn’t going to work

Yep.

Is :my_lib a dependency of the project?

Yes, exactly.

So when I compile the project (MyApp) I see

==> my_lib
Compiling 3 files (.ex)

[warn]  unavailable
Generated my_lib app
==> my_app
Compiling 82 files (.ex)
Generated my_app app

Thanks. That return code pretty much says its compiled everything and that module wasn’t found. Just to be really sure, the module is actually defined as defmodule MyApp.ConfigModule not defmodule Elixir.MyApp.ConfigModule?

Is :my_lib a dependency of the project? So that it will be compiled first, before the current project?

Elixir.MyApp.ConfigModule

unavailable

It would be helpful to know:

• What the result of Application.get_env(:my_lib, :some_config) is
• What the error return was (instead of ignoring it add it to the log message)