dcdourado
Module dependency (?) - Redefinition of attributes
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.
Most Liked
OvermindDL1
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).
dcdourado
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?
OvermindDL1
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!). ![]()
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








