included_applications can create erroneous circular dependencies

[okeuday]

When application A has included_applications specifying application B, and application B depends on A, relx gets an error about a circular dependency. The solution is to remove application A from the dependencies of all included_applications before checking the dependencies of application A (i.e., the act of including these applications satisfies their dependency on application A). An example is https://gist.github.com/okeuday/fb0d80f50fc13dc5b674 .

Using included_applications is not common, however, it does provide a way of merging applications so that the included_applications become part of the main application's supervision hierarchy. The general use case for included_applications is when the included_applications are not real OTP applications, or if the included_applications need special source code for supervisor initialization (perhaps configuration related). In CloudI, the cloudi_core Erlang application is using included_applications to include various CloudI services, so that cloudi_core can start them within its supervision hierarchy based on configuration (dynamic configuration, or the configuration file read at startup).

[ericbmerritt]

@okeuday we have not ignored this. We have just been talking about this amongst ourselves to figure out the best way to handle it.

[okeuday]

That is ok. As a temporary fix, I have commented out the application dependencies that make the tree cyclic, but it would be nice to uncomment the dependencies to make the dependencies explicit. Functionally, nothing should be different in the release, either way (i.e., with or without the cyclic dependency).

[jwilberding]

@ericbmerritt Did we ever address this?

[ericbmerritt]

No we have not. Its probably worth getting into a task list somewhere. Its has the potential to be non-trivial since we could only do that for included applications and not the other dependency types. This begs the question @jwilberding is it time to start thinking about an erlware task list?

[jwilberding]

@ericbmerritt Yeah, we either need to do something like a public trello, or
use the github wiki and/or issue tracker. What would you prefer? We could
also keep a TODO.md in the repo.

On Mon, Apr 7, 2014 at 5:06 PM, Eric Merritt notifications@github.comwrote:

No we have not. Its probably worth getting into a task list somewhere. Its
has the potential to be non-trivial since we could only do that for
included applications and not the other dependency types. This begs the
question @jwilberding https://github.com/jwilberding is it time to
start thinking about an erlware task list?

Reply to this email directly or view it on GitHubhttps://github.com//issues/57#issuecomment-39741870
.

[tsloughter]

So this is out oldest open issue @okeuday :). I really don't like the idea of cycles being ignored because the cycle is created by the app being included in included_applications.

Do you currently get around this with reltool somehow?

[okeuday]

@tsloughter I no longer need to worry about this in CloudI. I changed things to no longer use included_applications (for the CloudI services that are provided in the main repository). I have reltool including all the CloudI service applications (https://github.com/CloudI/CloudI/blob/develop/src/reltool.config.in#L33-L76), despite the fact they aren't part of the main dependency tree for the cloudi_core application.

However, I still think it is important to ignore cycles related to included_applications, just because it isn't related to the application being started, it is only a source code dependency and OTP is already ambiguous about which applications are started/loaded first (i.e., it is based on its traversal of the tree, it is not a deterministic sequential list, though that is the end result of a release within the script/boot file output).

[tsloughter]

@okeuday in a sense I'd agree, but I wouldn't want to make that to be a relx specific outcome when it isn't a relx specific config.

[okeuday]

My understanding is that this is a problem specific to relx, where reltool does not have this problem.

[tsloughter]

If that is true then I will make the modification. If you can find any documentation on this that would be great.

[okeuday]

I am pretty sure the only documentation related to this is what you probably have already seen at http://www.erlang.org/doc/man/app.html "All applications which are included by this application. When this application is started, all included application will automatically be loaded, but not started, by the application controller. It is assumed that the topmost supervisor of the included application is started by a supervisor of this application.". The fact it is only including the source code in the release and only loading the .app file at runtime for included_applications should justify ignoring the cyclic relationships they may create.