>
> 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.
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.
Resolving the start type between :permanent, :transient, and :temporary, is
simply determining precedence, which is given by that order.
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}
>
>
I think this solves the run-time vs compile-time determination, so I'm +1
> 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
>
>
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)
Where any items manually added to the applications list take precedence
over those which would be inferred. Is there any reason why adding
`extra_applications` is desirable?
Paul
On Wed, Sep 21, 2016 at 7:49 AM, José Valim <jose.va...@plataformatec.com.br
> wrote:
> After further discussion on IRC, we have raised some concerns about the
> latest proposal.
>
> 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.
>
> 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
>
>
> 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}
>
>
> With the features above, the list of applications, when not specified,
> will be calculated by:
>
>
> applications = (all_runtime_apps_from_prod_deps_ ++ extra_applications)
> -- included_applications
>
>
> This seems to be the simplest approach conceptually while solving the main
> problem of requiring users to explicitly specify the applications list.
>
> Final thoughts?
>
> --
> 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/CAGnRm4JZ%3D%2BUVsx%2BwAUy%3DMaO5%2Bk8oLSb1mbn_
> 7DmS03o9pMeOuw%40mail.gmail.com
> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JZ%3D%2BUVsx%2BwAUy%3DMaO5%2Bk8oLSb1mbn_7DmS03o9pMeOuw%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-Tu5GY7zHtjuaOkon%2B_4XyjoWQ6ornr3RkMF7M%2Bs%2B5k2kw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
