> The conflict resolution for this is actually pretty simple: if A specifies > [myapp: :load], and B specifies [myapp: :permanent], B wins, because B > cannot start if :myapp is not started, but A can still start if :myapp is > both loaded/started. >
I am afraid it may not be that simple. Because if A requires the application to only be loaded because let's say it needs to set some configuration before the application starts, we would need to make sure myapp is loaded before A and that myapp is started before B. So we need a slightly more complex dependency resolution which gets trickier in cases where B also has a dependency on A. This is how the conflict would have to be resolved for releases, aside from > just raising an error and requiring A to be modified to use :permanent as a > start type. > How would this conflict arise inside releases though if the type (permanent, load, etc) is specified in only one place? > I really feel like adding an extra field here doesn't simplify anything. > The algorithm could just as easily be: > > applications = applications ++ (all_runtime_apps_from_prod_de > ps_-- included_applications) > I would still like to have a mechanism where we disable the dependency guessing and that mechanism should be backwards compatible hence I think we should keep how :applications work today. Your code above also wouldn't work by default, it would require at least a call to Enum.uniq/2 (which means the application list is even more ambiguous from the user perspective). -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JoG%2B0pmLcLJt5Xciiw0UmVLAukkT0GLG4u0NOX7cRnPg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.