Umbrella dep precedence

[tsloughter]

I've been seeing some weird interactions when dealing with a project that has sub-apps where some have rebar.config's of their own with deps listed.

One issue I've nailed down is that the deps listed in the sub-apps take precedence over the top level, and I think it should be the other way around.

[ferd]

In general what is in the app's rebar.config overtakes what's in the parent (for example, erl_opts). For release you'd expect the parent to win though.

I don't know that there are clear rules there.

It sounds like the same project specifying the same dep twice at different versions should just not be legal rather than putting it everywhere, but I don't know what consequence this could have in existing projects.

[tsloughter]

I think top level wins is expected. It will already warn that there is a conflict, just like it does with deps.

[paulo-ferraz-oliveira]

deps listed in the sub-apps take precedence over the top level, and I think it should be the other way around.

Wouldn't it be even better if the base (as in "at the root folder") held the base deps and then whatever sub rebar.config you found would overwrite these in their own "hierarchy"?

should just not be legal rather than putting it everywhere, but I don't know what consequence this could have in existing projects.

I also like this idea (even though it could be potentially breaking, though easily fixed): when in conflict, just error out and stop.

In any case, having a clear visible rule is better than having no rule 😄.

[ferd]

The hierarchy is shared because only one version of any app can exist at any one time and be safely loaded (the many versions are for hot code loading only). So the problem with "overwrite within your hierarchy" is what do you do when 2-3 apps do the same thing but you still need to pick a winner for the project overall.

"pick whatever is closest to the root" is our default conflict resolution mechanism because it works for deps and transitive deps as well.

[paulo-ferraz-oliveira]

👍 I see...

What I also see as current behavior, for reference, is that:

• top-level wins (for deps), so that bit's done,
• if top-level isn't "in conflict" with an app, an app is chosen (I have mylib and mylib2, and my_lib wins),
• no warning is generated (if one should be).

So, should:

1. having a warning be enough (I think this is @tsloughter's idea in https://github.com/erlang/rebar3/issues/1925#issuecomment-432658677), or
2. the described situation be illegal (as per @ferd's https://github.com/erlang/rebar3/issues/1925#issuecomment-432641541)?

[mworrell]

I am running in exactly this issue. In our "umbrella build" we can have apps that include Hex packages that have deps that are already in the umbrella.

In relation to this I also observed that rebar3 first builds all deps and only then all umbrella apps. That gives problems if an umbrella app is used as a dependency by one of the deps. Is this defined behavior or an issue (as I suspect)?

[ferd]

Building deps before apps is a defined behavior, one of the earliest one established in Rebar3 before the first stable release.

[mworrell]

Thanks for clearing that up - rather unexpected for me, but at least it is clear.