included_applications can create erroneous circular dependencies about relx

[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 [email protected]:

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.