When a module attribute is based on the return of a function defined on another module, can we say we’ve a module dependency? Module A defines and exposes a module-attribute through a public function and Module B defines another module-attribute based on the return of that function.
This affirmation (module dependency) makes sense to me because module attributes are defined on compile time, and because of that Module B (which contains a module-attribute that depends on the definition of Module A) now has a dependency of Module A being before. Is this the correct concept?
Anyway, the real problem here is the redefinition of modules on this scenario. I’ve made a quick demo that shows that a redefinition on the module that possess the module-attribute won’t take any effect on the other module.
Is there a hook like @before_compile which can help me here? The main goal is to define some values and make Module A the single source of truth of these values, which will be used as guards, changeset validations and features based on this business-rule.
1 Like
So I cloned the demo, I ran mix deps.get && mix compile and then loaded it in iex via iex -S mix, I run:
iex(1)> {ModuleDependency.ModuleA.values, ModuleDependency.ModuleB.values}
{[:value_a, :value_b, :value_c], [:value_a, :value_b, :value_c]}
And they match, so then I edit the values in ModuleA by commenting the old values and uncommenting the commented new values, I then run this in that same iex session:
iex(2)> recompile
Compiling 2 files (.ex)
:ok
iex(3)> {ModuleDependency.ModuleA.values, ModuleDependency.ModuleB.values}
{[1, 2, 3], [1, 2, 3]}
And it worked fine here? You might need to give more details on what you are doing. Remember that module dependencies are handed by mix/compiler (pasting things in the REPL does not use mix/elixirc, calling recompile, which is just an import for IEx.Helpers.recompile/0 however does, mix/elixirc works on files, not interpreted code put in via the REPL in very short summary).
4 Likes
Thanks for the response @OvermindDL1!
On production level I can’t change the code and recompile it because of the difficulties of doing it on a running docker image and I’m afraid calling recompile command could harm a production-running application.
Given a scenario where a quick fix is required, pasting a module with changes on console may best than a full-deploy on terms of speed. Is this a legitimate worry? Should I be concerned about this?
2 Likes
Pasting code into the REPL will not perform any compiler-related cross-file work. The REPL is for interacting with a running system, not for compiling projects. ^.^
But what difficulties are you having with it in a docker container, I’ve had no issues here?
But still, when you’ve automated a full deploy with hot code swapping then it’s really really fast anyway (don’t even need to restart a docker container, hot code swapping is very nice!). 
2 Likes
My docker image basically copy project files, fetch deps, build and make release with Distillery.
I am not aware of how I could change the source code on the container and from this event the project updates the /bin application…
I will take further research on hot code swapping, thanks!
2 Likes
Yep! You can make a new release, copy it into the container (it doesn’t overwrite, it goes in as an actual release) then you ‘upgrade’ from one release to the other, which loads the new code, migrates data, keeps running old code in actors until they perform a new module call, etc… It works very well once set up if you want no downtime, it’s what we do here.
2 Likes
TBH this sounds like a recipe for disaster when the infrastructure spins up a new instance using that image; how would it get the “fix”?
2 Likes
Exactly, it won’t. This is a problem I’m aware of
Seems great, thanks for the tip!
Since the infrastructure here is based on k8s, it will get a little tricky to change the deployment strategy of docker-image pushes on registry, but I can see the benefits! Definitely will take some time to explore this option
1 Like
