> > 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 < [email protected]> 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 [email protected]. > 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 [email protected]. 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.
