Give feedback on failed dependency resolution

[msteiger]

Currently, the ResolutionResult class returns false when the resolutions fails. I would find it helpful to get more information on why that happened.

This could include the modules (version ranges) in the DAG that were missing or the dependency links (as modeled by the Constraint class).

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/11606101-give-feedback-on-failed-dependency-resolution?utm_campaign=plugin&utm_content=tracker%2F12992746&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F12992746&utm_medium=issues&utm_source=github).

[Cervator]

This could also be what we need to give the user more choice in the game setup menu - accepting newer module dependency versions after a disclaimer, for instance. Sounded like @Josharias was interested in helping out with that in the game menu piece :-)

[immortius]

Hmm. To be honest I had thrown this one in the too hard basket to worry about much later. I'm sure something is possible, although I think it might be separate from the Dependency Resolver. The problem with the algorithm used is it isn't clear to me how to detect the root cause of a resolution failure - and in fact there may be multiple root causes. Constraints don't fail - the are merely statements used to filter out options that can't be satisfied - and any given filtering out may be fine. It isn't until every version of a desired module is eliminated that you can be sure there is an issue, but then the cause isn't the constraint that eliminates the last version, but the initial constraints triggering the chain leading to the elimination of each version.

[keturn]

To be honest I had thrown this one in the too hard basket to worry about much later.

checks watch ⌚

Is five years later “much later” yet? 😉

but seriously, this is a huge source of frustration in trying to work in Terasology. You just get this message that says “failed” with nothing to follow up on and your only options are to walk away or try slamming your face into the wall again and hoping it doesn't hurt this time.

So after spending a couple hours with a debugger, I'm here in ResolutionAttempt.​VersionConstraint.​ConstrainFrom, figuring this is where stuff gets thrown out. (which is itself information! it was loaded in the first place and then excluded by a constraint, which is different than never-found.)

and I've got the debugger spitting this out when something's invalid

String.format("INCOMPATIBLE %s %s %s %s %s", 
    fromVersions, this, toVersions, 
    version.version.orElse(null), compatibility.versionRange);

which is starting to look almost useful, except I can't read this very well

[org.terasology.module.ResolutionAttempt$PossibleVersion@e9495]

so I think the bare minimum here is:

• implement PossibleVersion.toString
• implement CompatibleVersions.toString
• log something here at DEBUG severity when a constraint changes something
  • probably with an extra flag if that removal left only the empty set behind

and I guess that goes for constrainTo as well as constrainFrom

That's not going to make it back to ResolutionResult in a way that we can put a UI on top of, and it's not going to conclusively identify the point of failure (as you said, not all constraints lead to failure), but at least it'll give a person something to go on.

[keturn]

seems like it may also be useful to filter on dependencyVersion.isPresent(), I'm getting a lot of null there in constrainTo