The problem:
When a deep dependency throws an error on info/install/create step it's not as obvious in which nested reference an error occurred. Printing whole information (on error only?) would be very useful.
Current behaviour:
$ conan info . --only=None
DeepDep/1.0.0@user/stable: Not found in local cache, looking in remotes...
DeepDep/1.0.0@user/stable: Trying with 'bincrafters'...
DeepDep/1.0.0@user/stable: Trying with 'conan-center'...
ERROR: Unable to find 'DeepDep/1.0.0@user/stable' in remotes
Possible Solution?:
$ conan info . --only=None
ProjectA/1.0.0@user/stable:
- ProjectB/1.0.0@user/stable:
- ProjectC/1.0.0@user/stable:
- - DeepDep/1.0.0@user/stable: Not found in local cache, looking in remotes...
- - DeepDep/1.0.0@user/stable: Trying with 'bincrafters'...
- - DeepDep/1.0.0@user/stable: Trying with 'conan-center'...
ERROR: Unable to find 'DeepDep/1.0.0@user/stable' in remotes
in which nested reference an error occurred.
Why is it relevant?
At first sight, it doesn't look like an obvious thing because a graph is not a tree. For knowing the relationships between the nodes you can use later the conan info command.
@lasote as you can see in the example I attached in a situation when one of the dependencies is broken - conan info doesn't work and doesn't give you information about where such broken dep is located.
I ask about providing deep log trace on error, so the user can track broken deps.
Now I see. It is not a build error but a missing recipe error.
This kind of information would be useful too in case of conflict between requirements:
ERROR: Conflict in pcre/8.41@bincrafters/stable
Requirement bzip2/1.0.8@conan/stable conflicts with already defined bzip2/1.0.6@conan/stable
To change it, override it in your base requirements
We have the information that pcre is requiring bzip2/1.0.8, but conan does not show which package is requiring bzip2/1.0.6, so it is very hard to find out the package that needs to have its requirements updated.
I suggest making an additional flag for the conan info to force the indented output like that (names are welcomed).
@lasote I can look into it if such a solution would be okay.
:+1: In this case "fail fast" seems to be a wrong choice. Would be better to just mark packages as absent / conflicting / etc. Maybe with different command.
Another option could be to show, in error cases, the dependency chain from the package user asked to create/install/info to the offending package (the one which has no recipe, or the conflicting packages), something like ProjectA/1.0.0@user/stable -> ProjectB/1.0.0@user/stable -> ProjectC/1.0.0@user/stable -> DeepDep/1.0.0@user/stable
There can be several chain from ProjectA to DeepDep, showing any of them is a useful information, showing all of them would be even better.
About conflicts, we are working on this PR https://github.com/conan-io/conan/pull/5684 (issue https://github.com/conan-io/conan/issues/5617). Please comment there if you feel like the output already proposed is not good enough (or it is). Conan v1.19 should be ready shortly 馃檮
Most helpful comment
Another option could be to show, in error cases, the dependency chain from the package user asked to create/install/info to the offending package (the one which has no recipe, or the conflicting packages), something like
ProjectA/1.0.0@user/stable -> ProjectB/1.0.0@user/stable -> ProjectC/1.0.0@user/stable -> DeepDep/1.0.0@user/stableThere can be several chain from ProjectA to DeepDep, showing any of them is a useful information, showing all of them would be even better.