Poison not included in release

[bitwalker]

Poison not included in release

[hamiltop]

Project: https://github.com/hamiltop/systemex

[edgurgel]

I think that Poison needs to be included like this: https://github.com/edgurgel/poxa/blob/master/mix.exs#L17

Example:

 def application do
    [ applications: [ :logger, :crypto, :gproc, :cowboy ],
      included_applications: [ :jsex, :uuid, :signaturex ]
  end

applications are going to be started as dependency and included_applications will be just loaded.

In this case poison is not an application to be started, but just a "library" to be used.

[fishcakez]

applications are going to be started as dependency and included_applications will be just loaded.

That's not quite what included_applications means. included_applications are for applications whose supervision tree is included in the supervision tree of current application. This means that two applications can not both list the same application in included_applications. As a general rule it is good to avoid included_applications unless you specifically need to start another application's supervisor tree inside the application's supervisor tree. ranch is a good example where you might want to do this because the listeners tend to be started under ranch's supervisors.

Just because an application does not currently have a supervision tree it does not mean it won't in future, so there is no need to treat them differently.

Looking at the included_applications in poxa, they should be in applications because they are dependencies and not supervision trees included in poxa. These applications are still started but they do not have a supervision tree so starting appears to have little effect.

[edgurgel]

@fishcakez, yeah I think I misunderstood what included_applications are. One question:

In this case: https://github.com/basho/riak-erlang-http-client/blob/master/rebar.config

{deps,
 [
  %% ibrowse for doing HTTP requests
  {ibrowse, ".*", {git, "git://github.com/cmullaparthi/ibrowse.git",
                   "bbad869ea595c594912cf71fbd622aa80577c8f6"}},
   %% webmachine for multipart content parsing, will pull in mochiweb as a dep
   {webmachine, "1.10.3", {git, "git://github.com/basho/webmachine",
                          {tag, "1.10.3"}}},
   %% riak-erlang-client for riakc_obj
   {riakc, ".*", {git, "git://github.com/basho/riak-erlang-client",
                     "3038f3bcc23dd3b759c0f1124dab6ab4b8f3a9e0"}}
  ]}.

Where riak-erlang-http-client depends on webmachine (BUT just for some module that is not a "process") ? How do I add webmachine modules to be available and not start it ? Because if it start it, it will start mochiweb as well and so on, right? What would be the idiomatic way of saying: do not start, do not use any supervisor tree but let me use its modules?

[edgurgel]

From the documentation:

The application controller will automatically load any included applications when loading a primary application, but not start them.

I stopped at this point and didn't read the rest ;P

[fishcakez]

@edgurgel, don't list in applications but have the application loaded with: https://github.com/erlware/relx/blob/master/examples/relx.config#L63-L66

[edgurgel]

@fishcakez, thanks! Now the question is if exrm supports this configuration too.

[bitwalker]

@edgurgel Yep, definitely, always has, didn't have to fix any bugs to get it working or anything. Nope.

0.14.9 is out by the way.

@hamiltop Should be good to give the above advice a try. Let me know if you hit issues!

[edgurgel]

@bitwalker I see what you did :P

Thanks for such a fast feedback! Also thanks @fishcakez for this lesson on how to describe release dependencies 👍

[hamiltop]

Adding :poison under plain old :applications did the trick.

Is that standard best practices? Poison doesn't have a supervisor tree of any sort, it's just a collection of functions.

[fishcakez]

Is that standard best practices?

Yes but more than that, it's what you should do - except for the very rare exceptions mentioned above.

[bitwalker]

@hamiltop Do you feel like this issue has been resolved? Is there anything further I can do to assist?

[hamiltop]

Looks good. Thanks!

On Fri, Sep 19, 2014 at 11:55 AM, Paul Schoenfelder <
[email protected]> wrote:

@hamiltop https://github.com/hamiltop Do you feel like this issue has
been resolved? Is there anything further I can do to assist?

—
Reply to this email directly or view it on GitHub
#58 (comment).

[bitwalker]

Anytime!