tfwright
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.
Marked As Solved
kip
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.
Also Liked
kip
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.
kip
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)
kip
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
kip
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.
kip
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.
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Courses that'll move you from confusion to "Aha, now I get it!"
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
The deployment platform built for Elixir: PaaS ease, VPS control.
Courses that'll move you from confusion to "Aha, now I get it!"