Enhance user experience of manual version conflict resolution

[meggiman]

Using bender with larger SoC projects that contain many dependencies, we easily run into the issue, that there are semantic versioning conflicts that cannot easily be resolved in the short term (i.e. because the repo that requires version bumping is archived). Requiring to interactively point bender update to the right version to use every time we invoke bender update or to manually edit the overrides for all of these cases in the Bender.local file can become very cumbersome for larger projects. Since we already have the possibility to override the specific version to use in the Bender.local file I would suggest enhancing the update command to optionally remember the interactive conflict resolution decision of the user by appending the chosen version to the bender.local file. I think an optional flag to the update command that saves each decision to the bender.local file or a yes/no question after every decision would improve user experience.

[fabianschuiki]

This sounds like an excellent idea and is along the lines of what @micprog is already doing as part of the bender clone command. I like the idea of extending one of the generated files for that. We had a discussion of possibly annotating cloned working copies in the lockfile rather than the *.local; maybe information like manual conflict resolution preferences could go into the lockfile as well. What do you think, @micprog ?

[micprog]

I really like the idea, but see a bit of a conflict regarding the purpose of the update command. In my opinion, when calling update, all dependencies are re-resolved, but the problem here is that individual updates are not resolved without calling update, so in a sense multiple levels of update are needed. Maybe when this is added, update could incorporate a -f / --force flag to also re-resolve these set dependencies, otherwise only resolving the unset dependencies? I believe this ties in with the larger goal of having continuous dependency resolution. A quick temporary solution could work like clone, adding a line to the .local file, requiring manual deletion to fix.

[fabianschuiki]

I really like the idea, but see a bit of a conflict regarding the purpose of the update command. In my opinion, when calling update, all dependencies are re-resolved, but the problem here is that individual updates are not resolved without calling update, so in a sense multiple levels of update are needed. Maybe when this is added, update could incorporate a -f / --force flag to also re-resolve these set dependencies, otherwise only resolving the unset dependencies? I believe this ties in with the larger goal of having continuous dependency resolution.

Yeah I'd like to have this kind of behaviour where dependencies are not fully re-resolved all the time, but rather "unlock" if needed (e.g. a change to Bender.yml), or when explicitly asked for via -f / --force as you propose. It should also be possible to update a specific package, which would then iteratively further "unlock" other conflicting dependencies and update them until everything was resolved with the minimal set of updates.

A quick temporary solution could work like clone, adding a line to the .local file, requiring manual deletion to fix.

That sounds like a great start!