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


It's simpler if B has a dependency on A, since it means A has to be started
before B can be started, which would likely work out fine. But either way,
you can't know when A will start :myapp, or if it ever will, which is why A
would need to add :myapp to :included_applications, the .script which would
get generated would then load :myapp, load/start A, which would start
:myapp in it's top-level supervisor (after configuring it/etc.), then once
A (and thus :myapp are started), start B. This would happen with or without
the explicit dependency on A by B, since systools resolves the dependency
order of applications when it generates the .script for the release.

How would this conflict arise inside releases though if the type
> (permanent, load, etc) is specified in only one place?


I mean that is how it would be solved logically if applications could
specify their start type requirements for dependent apps - it's effectively
what must already be done today, just by hand.


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


Well, my code was more pseudo-code, as I mentioned, the manual entries in
applications would need to take precedence over anything inferred, which is
more complex than a single line of code can express clearly. You do bring
up a good point about backwards compatibility though, extending
:applications means that it would only work on that version of Mix or
greater.

I don't like the idea of "extra_applications" though, the name just doesn't
seem to express what the list is really there for - namely to provide
metadata about the load/start behaviour of applications. Maybe it's
simpler/clearer to break them out, e.g. "loaded_applications",
"started_applications", where the latter allows one to specify the start
type, defaulting to :permanent. Thoughts?

Paul



On Wed, Sep 21, 2016 at 10:45 AM, José Valim <
jose.va...@plataformatec.com.br> wrote:

>
>
>> 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%2B0pmLcLJt5Xciiw0UmVLAukkT0GLG
> 4u0NOX7cRnPg%40mail.gmail.com
> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JoG%2B0pmLcLJt5Xciiw0UmVLAukkT0GLG4u0NOX7cRnPg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAK%3D%2B-TvfwBxCAfJ%3D_LoLvO2QM8msC%2BZq8HTrSWj81t2S0WFwPA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to