> 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.

Reply via email to