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%2BAd5V5ga6sF1MkyC8zCo7WDRr4NFNMFNvmfKNKG6W1jg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
