>
> We are discussing two types of application configuration (hence the
> confusion)
>
> 1. If it is temporary, transient or permanent
> 2. If it should be started, loaded, included, none or skipped (am I
> missing any?)
>

I think it's unnecessarily confusing to split them apart that way, I think
a more logical split is like so:

1. {:start, :permanent | :transient | :temporary}, :load, :none - {:start,
_} isn't a thing of course, I'm just using it to reflect the grouping, but
these are the different choices for loading/starting dependent applications
when the top-level application starts
2. :included_applications - this is basically a variant of :load, but worth
keeping separate for purposes of this discussion, since it has some caveats
vs :load - namely that only *one* application in the entire app tree can
"include" a given application. The use of included applications is
basically to ensure that the lifecycle for that application is controlled
entirely by the including application. It's a horrible, confusing name for
what it does, but at the same time I don't have any better suggestions,
maybe "owned" instead of "included"? In any case, staying close to the
Erlang terminology is probably more valuable here, but it does annoy me.
3. :skip/:skipped_applications/:excluded_applications - Some logical
variant of this is basically what we need in order to bring Mix
applications and releases together.

All of the names I just mentioned for #3 however are pretty unintuitive,
which I guess is just one hangup here, the other being whether that's
really the right way to go about excluding apps. Ultimately, the desire
that we have is how to say "this application is not needed at run time for
my application, so I don't need it outside of compile-time". Maybe a
different start type (:compile) could be used to say "start this at
compile-time, but skip it when producing build artifacts (such as
releases)". Ideally, we could programmatically determine whether an
application is used at runtime, it seems like that's not possible (yet),
but it may be a path worth exploring unless there are hard limits on why it
doesn't work. One thought I had is that it should be possible to dump
imports for a module from the BEAM info and map those back to their owning
applications, and using that to determine what apps are truly needed at
run-time. Thoughts?

Paul



On Tue, Sep 20, 2016 at 6:27 PM, José Valim <jose.va...@plataformatec.com.br
> wrote:

> You mean the implementation from Distillery which automatically
>> constructed the applications list?
>>
>
> Sorry, I meant your idea of adding release information to the list of
> dependencies.
>
>
>> 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.
>>
>
> It was a very quick exchange in private on IRC. Basically we want to
> support something like start_applications: [foo: :load], as you proposed
> later on, but we decided to not do that because we would need to change how
> Mix starts applications (today it starts applications by mostly calling
> Application.ensure_all_started/2). However, if the goal is to make it
> closer to releases, then the work may be worth it.
>
>
>> 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 permanent
> 2. If it should be started, loaded, included, none or skipped (am I
> missing any?)
>
> And to agree with your last paragraph: I believe everyone agrees at this
> point we should infer the applications and that bringing applications and
> releases together is a good idea. The next question then is: how to make
> this all possible?
>
> --
> 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/CAGnRm4%2B9x%2BVdar9vFcMk_GzjFOnpVe_j8EfBKP2gS9%
> 2BG92g5Uw%40mail.gmail.com
> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2B9x%2BVdar9vFcMk_GzjFOnpVe_j8EfBKP2gS9%2BG92g5Uw%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-TsvjP3ic0JH_DX-FxRLa-o59LirSN1iJH6bC-JjVZOOzw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to