Re-resolve when lockfile is invalid

[deivid-rodriguez]

What was the end-user or developer problem that led to this PR?

Sometimes, even if we give a warning about it, we may end up installing gems incompatible with each other.

What is your fix for the problem, implemented in this PR?

My fix is to move the check for unmet dependencies in lockfile just in time to be able to re-resolve if unmet dependencies are found.

Still missing a spec.

Make sure the following tasks are checked

• Describe the problem / feature
• Write tests for features and bug fixes
• Write code to solve the problem
• Make sure you follow the current code style and write meaningful commit messages without tags

[martinemde]

This looks like a much better approach.

[deivid-rodriguez]

Thanks @martinemde!

[etiennebarrie]

Tested this and it works great, I get a non-zero exit status code (6 for some reason, I don't think that's publicly documented), the error message is really good. Thank you!

I don't see anything checking the return value explicitly in the spec though, the raise_on_error: false allows the command to fail but does not make sure it does.

Also while looking into this, I found this, which sounds 6 shouldn't go all the way to the exit status of the command:

rubygems/bundler/lib/bundler/errors.rb

Lines 23 to 24 in 956ecb8

	# Internal error, should be rescued
	class SolveFailure < BundlerError; status_code(6); end

[deivid-rodriguez]

You're right, happy to take a PR to add that assertion. We have helpers for checking that no gems were installed, and also for checking that the last command returned a failed status.