Conditional code based on config

I have a library (MyLib) that I use for part of another app’s functionality (MyApp). I’d like to add some conditional code (an Ecto schema definition) to one of the library’s modules only if MyApp has a particular config that points to one of MyApp’s modules (also an Ecto schema). I was hoping to call a function on the MyApp module to get the info about it I need, but it appears to break compilation in certain circumstances because MyApp hasn’t been compiled yet (I was trying to call __schema__/2 to get info about an association).

One option would be to require the MyApp config specify all the data MyLib needs, but that feels a bit clunky and redundant. Is there a way to force MyApp to compile first so that MyLib can access its module’s functions during compilation time? Or is there another, better way to go about what I’m trying to do?

Appreciate any tips/suggestions.

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.

1 Like

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)
1 Like

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

1 Like

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.

1 Like

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.

1 Like

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 (:scream:), 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.

1 Like

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.

4 Likes

Thank you!

1 Like