I have a library I’ve owned for some time, beardedeagle/mnesiac, and over the last few years I’ve noticed several people forking the repo to remove :mnesia
from application/0
. I figured, if it’s happened more than a couple times, I’d take a look into it and see if that’s something I should change in the library proper.
So, digging into it, I see two potential reasons for why people are doing this:
- Since I had
:mnesia
inincluded_applications
, if they used any other libraries that utilized mnesia but had it inextra_applications
, it would cause issues for releases unless they specifically did what is outlined here: Adding deps to included_applications raises on release · Issue #9683 · elixir-lang/elixir · GitHub - They want complete control of the who/what/when/where/why mnesia is started or owned in their application/library.
That last point really resonates with me, as I want consumers to have complete control around the specifics around mnesia start/ownership. I put mnesia into included_applications
in an attempt to ensure it was loaded, but not started by my library. However, if I remove mnesia from application/0
in my mix.exs, my test suite will understandably start throwing warnings like the following:
warning: :mnesia.add_table_copy/3 defined in application :mnesia is used by the current application but the current application does not depend on :mnesia. To fix this, you must do one of:
If :mnesia is part of Erlang/Elixir, you must include it under :extra_applications inside “def application” in your mix.exs
If :mnesia is a dependency, make sure it is listed under “def deps” in your mix.exs
In case you don’t want to add a requirement to :mnesia, you may optionally skip this warning by adding [xref: [exclude: [:mnesia]]] to your “def project” in mix.exs
So now I’m trying to figure out the best way to handle this. Here is my understanding of things so far:
- Keeping mnesia in
included_applications
doesn’t start mnesia, but the mnesia process itself would be owned by mnesiac as far as I can tell, which I don’t want. Also, this violates the first point above. So, this is out. - Putting mnesia into
extra_applications
with:optional
won’t work for what I’m trying to do as the only thing that does is ensure that my library startup won’t be impacted in the event that mnesia isn’t available to start. Also, the goal here is to make it so my library doesn’t start mnesia which as far as I can tellextra_applications
will do, so this is out. - I could
xref: [exclude: [:mnesia]]
. I’m not particularly a fan of this as to me, it makes it seem like the library doesn’t need mnesia when it clearly does.
I am unsure there is a better way to handle this than excluding it from xref
though. I’m also unsure if doing this via the xref
method would have any other potential pitfalls I’m not considering. Any suggestions, pointers or docs would be greatly appreciated here. Thank you in advance.