Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Why use applications: for run-time dependencies? #190
I understand that all run-time dependencies need to be declared in the mixfile
My understanding had been that this list is essentially passed through to the
On the surface, this makes it seem like Distillery is borrowing this mechanism to determine what to include in the release package. Is there some underlying Erlang detail that forces the OTP application startup to be coupled to the run-time module dependencies?
Distillery already inspects the
Another alternative would be for Distillery to get this from its own
Up until Elixir 1.4, we couldn't use the dependencies list because some things which we don't want in the release package must be dependencies in the environment used to build the release - basically, any build-time tools (distillery itself is such an example, it has to be present when
So to answer your question more directly, the way it works today is due to legacy behaviour. Beyond that though, there has always been a hesitation to infer meaning from the dependencies list, when there isn't a 1:1 correlation with the applications list - they don't mean the same thing, even though you effectively have to put everything your application depends on at runtime in the applications list.
Distillery will be moving to support the new
I can understand the reluctance to use the build-time dependencies list.
For the sake of argument, say my app has some non-start/stoppable library application in its
Distillery when it supports adding things from the deps list, will add them to the applications list with a start type of
A better reference for how releases are constructed can be found here. The