Declare an OTP application as a dependency without putting it in application/0?

Questions / Help
, ,
1

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:

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:

  1. If :mnesia is part of Erlang/Elixir, you must include it under :extra_applications inside “def application” in your mix.exs

  2. If :mnesia is a dependency, make sure it is listed under “def deps” in your mix.exs

  3. 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 tell extra_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.

2

Would making your application/0 conditional on Mix.env() so that:mnesia is only included for development/testing purposes, but not “prod” package publishing purposes, work? Ex. this example

1 Like
3

Mmm…unfortunately not I think, the warnings actually show up during compilation. If a consumer is passing --warnings-as-errors to mix compile, it would fail, which would also be a poor user experience. It’s a good idea I hadn’t considered though.

4

Why does your testsuite compile for users of your library?

5

Another option may be to keep it in applications but the user setting mnsia to load in their release so they can start it where ever they want.

1 Like
6

Unless I’m blind, I don’t seem to be able to edit my original post anymore. The warnings get thrown during compilation, not specifically when I run my tests.

7

Yeah, that’s a possibility. Basically, move mnesia to extra_applications and explicitly document how to utilize load with mnesiac.