internal: Fix lockfile constraint output for 1.2.* #26637
Conversation
Codecov Report
|
There was a problem hiding this comment.
This looks good to me!
The reporter asked a good question in the attached issue (not a question that would hold up this PR): should terraform require full major.minor.patch version constraints when specifying an exact match w/ =?
I'm ok with not requiring that as long as it's clearly documented that = 2.0 is equivalent to = 2.0.0, especially if = 2.0.0 is what terraform displays in the UI, but it's worth thinking about.
| @@ -422,27 +422,24 @@ func VersionConstraintsString(spec VersionConstraints) string { | |||
| b.WriteString("??? ") | |||
| } | |||
|
|
|||
| // The parser allows writing abbreviated versions (such as ~> 2) which | |||
| // end up being represented in memory with trailing unconstrained parts | |||
There was a problem hiding this comment.
(dang it gh this is the 4th time I've written this comment PLEASE STICK THIS TIME)
I know this isn't a new comment, but I have a nitpicky request while you're in the area: reading this briefly (before my brain kicked in) lead me to expect that a constraint written as ~> 2.0 would be recorded as 2.0.0 (exact). It's silly, but can you clarify that comment? I don't know if my suggestion (below) is the right idea but something like it would have saved me a lot of time this morning 🙃
There was a problem hiding this comment.
I think your suggestion below is correct, but in rereading the comment I also spent 10 minutes confused, so I think it's probably structurally unclear. I'll take another shot at it. Thanks for pointing this out!
There was a problem hiding this comment.
Here's another attempt. Is this any clearer to you?
There was a problem hiding this comment.
YES thank you!! That's fantastic!
If a configuration requires a partial provider version (with some parts unspecified), Terraform considers this as a constrained-to-zero version. For example, a version constraint of 1.2 will result in an attempt to install version 1.2.0, even if 1.2.1 is available. When writing the dependency locks file, we previously would write 1.2.*, as this is the in-memory representation of 1.2. This would then cause an error on re-reading the locks file, as this is not a valid constraint format. Instead, we now explicitly convert the constraint to its zero-filled representation before writing the locks file. This ensures that it correctly round-trips. Because this change is made in getproviders.VersionConstraintsString, it also affects the output of the providers sub-command.
alisdair
force-pushed
the
alisdair/fix-locksfile-unconstrained-versions
branch
from
391987b to
9576a5b
Compare
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
ghost
locked as resolved and limited conversation to collaborators
If a configuration requires a partial provider version (with some parts unspecified), Terraform considers this as a constrained-to-zero version. For example, a version constraint of
1.2will result in an attempt to install version1.2.0, even if1.2.1is available.When writing the dependency locks file, we previously would write
1.2.*, as this is the in-memory representation of1.2. This would then cause an error on re-reading the locks file, as this is not a valid constraint format.Instead, we now explicitly convert the constraint to its zero-filled representation before writing the locks file. This ensures that it correctly round-trips.
Because this change is made in
getproviders.VersionConstraintsString, it also affects the output of the providers sub-command.Fixes #26631.