def application do
[otp_applications: [:logger],
skipped_applications: [...],
included_applications: [...]]
end
applications = ((all_apps_for_prod_deps ++ otp_applications) -- included_applications) -- skipped_applications
def application do
# List only applications from Elixir and Erlang required in prod
[otp_applications: [:logger]]
end
I do think that the name OTP applications is unclear.
How does one determine if a production dependency is an application or not?
configure_applications: [logger: :start, other: :included, compile_time_only: :skip]
def application do# Any application that does not come from a dependency, such# as Erlang and Elixir applications must be explicitly listed.[start_applications: [:logger]]end
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4Lh%3Dp4bokfCv6KiG5dRGJHqXUkQOyMMogEzGXrfpd2G_w%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAK%3D%2B-Tt7jDioik%2B9AwhHca8grUkuKdiHi9%2BgNSzE0%2BofKyDvjw%40mail.gmail.com.
James also proposed something related to your dependencies list but we discarded the idea because we also didn't feel it was correct. So far dependencies are about getting the sources into your system and compiling them to applications.
James also proposed some features that would require us to change how Mix starts applications and while at first we decided to not do that, I now realize it may be worth pursuing since it will help bring Mix and releases together.
In other words, it may be worth looking for a mechanism that allows us to specify the application type directly in def application and make sure both releases and Mix respect those types.
My only concern is that, although it may be compelling to bring applications and releases metadata together, releases may have multiple targets and therefore may still need to add their own configuration. So it is important whatever format we choose can be used for both applications and releases.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BAd5V5ga6sF1MkyC8zCo7WDRr4NFNMFNvmfKNKG6W1jg%40mail.gmail.com.
You mean the implementation from Distillery which automatically constructed the applications list?
Could you provide some details on that, or link to the previous discussion? I'd be interested in reading about the proposed change just for the context.
I like this idea, though without more information I'm not precisely sure what is meant by "application type" here. Do you mean that in `def application`, one would flag whether their app is a compile-time vs. runtime application?
We are discussing two types of application configuration (hence the confusion)1. If it is temporary, transient or permanent2. If it should be started, loaded, included, none or skipped (am I missing any?)
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2B9x%2BVdar9vFcMk_GzjFOnpVe_j8EfBKP2gS9%2BG92g5Uw%40mail.gmail.com.
def application do
# Any application that does not come from a dependency, such
[extra_applications: [:logger]]
end
{:distillery, ">= 0.0.0", runtime: false}
applications = (all_runtime_apps_from_prod_deps_ ++ extra_applications) -- included_applications
The issue with supporting entries such [myapp: :load] or [myapp: :permanent] is what happens when projects A and B specify different properties for :myapp. We would need to solve conflicts and that would introduce complexity which otherwise does not exist on releases because relaeses specify this metadata only once.
We will also support the :runtime option (or something more appropriately named) for dependencies that allow us to specify a dependency is not necessary during runtime. For example, distillery itself would be specified as:{:distillery, ">= 0.0.0", runtime: false}
Therefore, one last proposal is the following:def application do
# Any application that does not come from a dependency, such# as Erlang and Elixir applications must be explicitly listed.[extra_applications: [:logger]]end
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JZ%3D%2BUVsx%2BwAUy%3DMaO5%2Bk8oLSb1mbn_7DmS03o9pMeOuw%40mail.gmail.com.
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.
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.
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 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.
How would this conflict arise inside releases though if the type (permanent, load, etc) is specified in only one place?
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JoG%2B0pmLcLJt5Xciiw0UmVLAukkT0GLG4u0NOX7cRnPg%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
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.
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?
The last proposal completely dropped the ability to set an application as permanent, temporary, etc. hence the name :extra_applications. If we are going to have such ability, I would stick with :start_applications previously proposed.
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BRcrmMZcfmivW9Hp3sQx_U56%3Dg38OjkonpFQoOv%3DTc5g%40mail.gmail.com.