>
> 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.


You mean the implementation from Distillery which automatically constructed
the applications list? Yeah it was flawed because it always included
dependencies, even if they were compile-time only. I do think there is
generally a 1:1 correlation with prod dependencies and applications which
should be part of the release, but there are obviously exceptions,
Distillery itself being one - this was ultimately why I removed the
automatic inference. Sadly there doesn't seem to be a clear way to
automatically determine what applications are only used at compile-time vs
runtime.

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.


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.

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.


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?

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.


I think release configuration can (or should) be viewed as a superset of
application configuration - in other words, releases build on the
application configuration, they don't differ from it. The configuration for
a specific release target shouldn't countermand the configuration for the
application(s) it's based on. To be clear for everyone reading, by
"application configuration", I don't mean runtime config stuff that goes in
`config.exs`, but rather the application definition from `mix.exs`. But
perhaps some specific real-world examples may show where this falls down -
so far in my experience, the above holds true.

Paul


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

> Thank you Paul for your feedback, it is very valuable for this discussion.
>
> Once we consider releases, there are at least three level of
> configurations happening here:
>
> 1. dependencies (which are mostly about getting the dependencies sources
> to your system
> 2. applications
> 3. releases
>
> 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.
>
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R&D
>
> On Tue, Sep 20, 2016 at 4:53 PM, Paul Schoenfelder <
> paulschoenfel...@gmail.com> wrote:
>
>> I actually built exactly this feature into Distillery, but then removed
>> it because I didn't have a good solution for omitting build-time only deps.
>> I considered an option on dependencies, i.e. `release: false`, but that
>> didn't feel right, and I didn't want to overload the meaning of things in
>> the applications list.
>>
>> We can infer the entire list of applications for prod dependencies
>> without having to specify anything in the `:applications` list, but there
>> are two other things we need to be able to specify, application start type
>> (`included_applications` is *not* for this, it is for taking over the
>> application lifecycle of the applications in that list, and only one app in
>> a given release can include an application), and compile-time only deps.
>>
>> The former is solved by simply setting the start type in the applications
>> list we already have, i.e. `myapp: :load`, this is already supported today
>> - we just need a mechanism for the latter. `skip_applications` seems like a
>> reasonable option to me, flagging deps seems like another, but as I
>> mentioned above, I'm not sure it feels right.
>>
>> I don't agree that "OTP application" has a double meaning, it has a very
>> clear definition, which is any application that conforms to the OTP
>> structure (i.e. has a supervisor tree). The thing is, regardless of whether
>> an application is an OTP application or simply a library application, it
>> has to be included, so I find the distinction not particularly useful.
>>
>> Paul
>>
>> On Tue, Sep 20, 2016 at 6:46 AM, José Valim <
>> jose.va...@plataformatec.com.br> wrote:
>>
>>> Another idea is to focus on the most common case and built on top of
>>> that:
>>>
>>>   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
>>>
>>>
>>> But you can also pass ", other: :included, compile_time_only: :skip".
>>> The new :start_applications cannot be used alongside the old
>>> :applications/:included_applications options.
>>>
>>> *José Valim*
>>> www.plataformatec.com.br
>>> Skype: jv.ptec
>>> Founder and Director of R&D
>>>
>>> On Tue, Sep 20, 2016 at 1:26 PM, José Valim <
>>> jose.va...@plataformatec.com.br> wrote:
>>>
>>>> One other option is to have something called configure_applications
>>>> (although something shorter would be ideal):
>>>>
>>>> configure_applications: [logger: :start, other: :included,
>>>> compile_time_only: :skip]
>>>>
>>>>
>>>> We will automatically include all production deps but you can remove or
>>>> add something by using configure_applications.
>>>>
>>>> Further thoughts?
>>>>
>>>> *José Valim*
>>>> www.plataformatec.com.br
>>>> Skype: jv.ptec
>>>> Founder and Director of R&D
>>>>
>>>> On Tue, Sep 20, 2016 at 11:19 AM, José Valim <
>>>> jose.va...@plataformatec.com.br> wrote:
>>>>
>>>>> I do think that the name OTP applications is unclear.
>>>>>
>>>>>
>>>>> I agree. It has a double meaning: we can call all applications an OTP
>>>>> applications or we can call the ones that ship part of OTP (the standard
>>>>> library) an OTP application. Suggestions for better names? We could call 
>>>>> it
>>>>> `kernel_applications` or `stdlib_applications` if that's clearer?
>>>>>
>>>>>
>>>>>> How does one determine if a production dependency is an application
>>>>>> or not?
>>>>>>
>>>>>
>>>>> Production dependencies must always be applications unless you have a
>>>>> very special case of a production dependency that is compile-time only 
>>>>> (and
>>>>> I can't recall of 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+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/elixir-lang-core/CAGnRm4Lh%3Dp4bokfCv6KiG5dRGJHqXUkQOyMM
>>> ogEzGXrfpd2G_w%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4Lh%3Dp4bokfCv6KiG5dRGJHqXUkQOyMMogEzGXrfpd2G_w%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/ms
>> gid/elixir-lang-core/CAK%3D%2B-Tt7jDioik%2B9AwhHca8grUkuKdiH
>> i9%2BgNSzE0%2BofKyDvjw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/elixir-lang-core/CAK%3D%2B-Tt7jDioik%2B9AwhHca8grUkuKdiHi9%2BgNSzE0%2BofKyDvjw%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/CAGnRm4%2BAd5V5ga6sF1MkyC8zCo7WDRr4NFN
> MFNvmfKNKG6W1jg%40mail.gmail.com
> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BAd5V5ga6sF1MkyC8zCo7WDRr4NFNMFNvmfKNKG6W1jg%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-Tvs3SNTsxx08%3DiFZk53u9rwFVTjUD6T2dy1XTu11ZQM1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to