Detect Pants-generated lockfiles before attempting to validate. #17833
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously we would use the value of the python-only resolves_generate_lockfiles option to decide whether user lockfiles were expected to be Pants-generated, and therefore subject to validation, or not. And we would always validate tool lockfiles, which were expected to always be Pants-generated. With this change, the lockfile parsing code raises a new exception subclass if the lockfile has no "Generated by Pants" header block, This allows us to differentiate between "this is a Pants-generated lockfile with invalid metadata", which remains an error, and "this is not Pants-generated at all", in which case we silently skip validating metadata. The only case where this behavior is different from the previous behavior is if you had a lockfile that did have that header, but the user wanted Pants not to validate it, which is such a perversion of the intent of this feature (which is to support lockfiles generated manually using pex or poetry) that I see no need to worry about it. This is part of a sequence of planned changes to unify tool and user lockfiles into a single mechanism.
|
I set this label to "user-api-change" because of that extremely unlikely perverse case, but could also just go with "internal". |
jsirois
approved these changes
Dec 17, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Previously we would use the value of the python-only resolves_generate_lockfiles option to decide whether user lockfiles were expected to be Pants-generated, and therefore subject to validation, or not. And we would always validate tool lockfiles, which were expected to always be Pants-generated.
With this change, the lockfile parsing code raises a new exception subclass if the lockfile has no "Generated by Pants" header block. This allows us to differentiate between "this is a Pants-generated lockfile with invalid metadata", which remains an error, and "this is not Pants-generated at all", in which case we silently skip validating metadata.
The only case where this behavior is different from the previous behavior is if you had a lockfile that did have that header, but the user wanted Pants not to validate it, which is such a perversion of the intent of this feature (which is to support lockfiles generated manually using pex or poetry) that I see no need to worry about it.
This is part of a sequence of planned changes to unify tool and user lockfiles into a single mechanism.