Possible problem with rebar3 upgrade

[tothlac]

This is a kind of rare situation probably not too easy to reproduce but if needed I can create the example applications and push it to github.

Let's say I have the following app structure:

tothlac:myapp rebar3 tree
===> Verifying dependencies...
└─ myapp-git (project app)
   ├─ app_a-git (git repo)
   │  └─ app_b-git (hex package)
   └─ ─ app_c-git (git repo)
        └─ app_d-git (hex package)

It compiles, everything works, except rebar3 upgrade. It says:

===> Dependency cycle(s) detected:
applications: **app_b app_d depend on each other**

This is our problem, since the current versions of the app_b and app_d are referencing each other. But this is only on the versions which were referenced in rebar.lock. The applications section of the app.src files were referencing the other app in both applications.

On the current versions of the two apps we don't have this problem. Only app_b.app.src includes app_d in the applications paragraph.

Simply deleting rebar.lock, deleting the other app from the app.src file, or deleting the entire _build directory did not solve the issue.

The only way to fix it was to delete app_a from rebar.config, and call rebar3 upgrade so app_a and app_b were deleted from rebar.lock, then add back app_a and call rebar3 upgrade again.

Would be there an automated solution to get out of this deadlock state?
The upgrade in this case was not possible because in the current state the two apps are refencing each other vice versa. Maybe one of these vice versa connections should be temporarily deleted from the dependency graph?

The other thing is that if you follow connections defined by the deps section of rebar.configs or the application section of the app.src files, it defines a graph not a tree.

Is not it possible to execute the upgrade command following only the connections revealed by rebar3 tree. As the output of the command is a tree those connections would not cause this problem.

[ferd]

The other reason the upgrade wouldn't be possible is that unless you upgrade either a or c, they should usually be guaranteed to result to the same dependencies, since they are locked and should be repeatable.

No matter what you do, it would logically make sense that both apps end up in exactly the same state they were, since we try to offer reproducible builds.

I guess just calling rebar3 upgrade a wouldn't work because we detected the loop in the deps before running the upgrade sequence, though? I would have expected it to work, but you're telling me it does not, right?

And yeah, rebar3 tree is a tree of which deps were brought in by which app. It initially was meant to help people debug why they ended up with the versions they have. A tree command without this format would not serve its initial purpose, though. Maybe deps could be overhauled for that, but I Don't know.

[tothlac]

No, rebar3 upgrade did not solve this issue. I also tried to delete rebar.lock, manually upgrade the commit ids of the deps in rebar.lock, deleted the _build directory. Neither of them was able to bring rebar3 out of this stuck state. Only trick was the above mentioned "workaround".