Using it means you are responsible for managing the full lifecycle for the included application - additionally, only one application in the tree can include a given application (i.e. app
b can’t both have
c in their
included_applications). This should be self-evident (how can two applications manage the startup of some other application), but it definitely can cause confusion. I haven’t tested what happens if
a depends on
b, and contains
c in it’s
b also depends on
c but has it in it’s
applications list. Presumably nothing good happens there, and you’d need to take over both
included_applications, but as I mentioned, I don’t know for sure.
More often than not, all you really want is to set the start type of a given application to
:load, start it post-configuration phase, and that’s that. You can do this pretty easily with Distillery, but I don’t think it’s possible via
mix.exs currently AFAIK (or perhaps that’s what
extra_applications is for in 1.4+, I’d need to double check). Again though, if you have a dependency which depends on that app being started, you would likely need to set it’s start type to
:load as well, but I haven’t tested this (haven’t actually encountered this problem yet).
In any case, it’s not that there is something wrong with using
included_applications, it’s just that the other approach is better and less error-prone.