Don't panic if the new version constraint parser is stricter than the old one #25223
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The new provider install logic for 0.13 uses a different version constraint parser that makes an effort to produce user-actionable error messages when the user enters something invalid or non-sensical, but as of right now the
configs
package is still in an in-between state between old and new because we didn't change the other places where version constraints appear to use the new parser yet.The new parser is intentionally a little stricter than the old one, because it's no longer just a regex match and aims to give feedback when it finds something weird, but it was inadvertently a little too strict in that it was enforcing the space between the operator and the boundary like in
~> 1.0.0
, due to a mistaken impression on my part that this was required by rubygems (which our constraint syntax is based on). Turns out that rubygems does accept the space being absent and that's just not mentioned in any of the documentation.So with all of that said, there are two different things in this PR:
Accept a constraint like
~>1.0.0
as equivalent to~> 1.0.0
, which is non-idiomatic but also a pretty harmless thing to be making a fuss about. (That's achieved by upgrading the upstream dependency containing the parser.)If the input contains any other case where the new parser is stricter than the old (which should, after the change mentioned in the previous item, be much more marginal things that would be unlikely to appear in real configuration), return it as a proper error message rather than a panic.
I did consider going all the way to switching over to the new parser for other cases here, but that ended up being too invasive a change to make this close to final release, and so instead this is a short-term robustness improvement, focused only on avoiding panics, with the intent of using the new parser exclusively in a future release.
This closes #25177.