I need to write tests for my app involving the types in ex_money and money. Unfortunately (for me), both the projects name their types as Money.
In my mix deps(), both ex_money and money are also available in the dev env, so in an IEx session, I did:
iex(6)> i Money
...
Source
deps/ex_money/lib/money.ex
...
even if I changed the order of listing the deps. It looks like the module definition is being overwritten, which is (IMO) expected behaviour, though I don’t know why ex_money trumps money all the time
It does print a warning about the redefinition:
warning: redefining module Money (current version loaded from /some_path/_build/dev/lib/money/ebin/Elixir.Money.beam)
The only solution that comes to my mind is to load them in separate test environments, and write tests for ex_money in one, and for money in the other.
TL;DR
Is there a way to reference modules with the source file or “project” they were defined in?
If you have two different projects that have User modules that shouldn’t matter because one should be ProjectOne.User and the other should be ProjectTwo.User. What exactly is it that you want to do and how are you naming them currently?
Edit: Everything before “TL:DR” was added to the post after I wrote this response.
You simply can’t use those packages at the same time.
What might be possible if you do not fear hell and other hot places, to manage those deps on your own, during runtime. loading and unloading on your own…
Proper way though, where to file a bug in ex_money that its naming scheme violates conventions and clashes with other packages. I’m not sure if he will rename the module(s) though, since it will break everything depending on his package
Thanks for your help, and confirming my doubts. As this was not mission critical to the project internals, and the tests were just for documenting examples to show that we can work with all of Elixir’s 3 Money libs, we won’t be loading multiple Money libs in the test env now.
@NobbZ We did mull on runtime load-unload, but that’s surely an overkill for us. And as @Schultzer has pointed out, it’s very unlikely that a project would need multiple Money libs, so I’m not raising an issue with their authors.