This sounds better to me too, `extra_*` has some odd connotations that makes it seem like it does not belong...
On Wednesday, September 21, 2016 at 10:26:48 AM UTC-6, Paul Schoenfelder wrote: > > 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....@plataformatec.com.br <javascript:>> 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_deps_-- 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-co...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JoG%2B0pmLcLJt5Xciiw0UmVLAukkT0GLG4u0NOX7cRnPg%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/e114f2fc-1e5e-4640-873c-28130f3436f7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
