Conditional code based on config

You may need to use Code.ensure_compiled/1 to force compilation order if it isn’t being detected the way you want.

The documentation notes that this is not a function you should commonly reach for. However forcing compilation order at compile time is one reasonable use.

This doesn’t seem to work for my use case, perhaps I using it incorrectly? My current implementation looks like this:

MyLib.MyModule
  if Application.get_env(:my_lib, :some_config) do
    case Code.ensure_compiled(Application.get_env(:my_lib, :some_config)) do
      {:module, module} -> # do something with module
      {:error, _} -> Logger.warn("couldn't compile")
    end
  end

Instead of breaking compilation #do something with module fails to run and I get the warning instead. The docs says the function

halts the compilation of the caller until the module given to ensure_compiled/1 becomes available or all files for the current project have been compiled. If compilation finishes and the module is not available, an error tuple is returned.

I’m not sure what “project” technically means here. I had hoped it meant something like “MyApp and all deps except the current one”, but it looks like it just means “all files in MyLib except this one”?

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)

Elixir.MyApp.ConfigModule

unavailable

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?

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

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

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.

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.

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.