Module dependency (?) - Redefinition of attributes

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).

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?

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!).

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!

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.

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”?

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