Silence the scie-pants version warning when NO_SCIE_WARNING=1#19660
Merged
Silence the scie-pants version warning when NO_SCIE_WARNING=1#19660
Conversation
benjyw
approved these changes
Aug 23, 2023
github-actions Bot
pushed a commit
that referenced
this pull request
Aug 29, 2023
Before this fix, #19654 was causing `pants ...` commands in the pants repo to explode and not work. This fixes it by silencing them in the pants repo, keying off the existing `NO_SCIE_WARNING=1` mechanism. Running scie-pants in the pants repo goes through a special bootstrap mechanism, that's bootstrapped outside the scie-pants processing on purpose. This in particular means that the scie-pants version check from #19600 / #19654 doesn't work, because it's not invoked via that mechanism. Fortunately, this can just be treated the same as the "am I running in scie-pants at all?" check, looking for the env var set by the pants repo bootstrapper. The version check has to be strict about the `SCIE_PANTS_VERSION` environment variable, and it cannot just do nothing when that's not set. The goal with this check is to help people using upgrade to scie-pants 0.9+ _before_ Pants 2.18 is released, because Pants 2.18 has a new distribution mechanism that's only supported by scie-pants 0.9+ (this is why we needed to land #19654 last minute, to be in Pants 2.17). scie-pants only sets the environment variable in version 0.9 too, so a user using scie-pants 0.8.0 will be running Pants 2.17 without setting `SCIE_PANTS_VERSION`, and so, to help them upgrade, we have to assume "doesn't exist" = "scie-pants is too old". The pants repo custom bootstrap doesn't set this env var, and hence used to fall into that trap.
Member
|
I tried to automatically cherry-pick this change back to each relevant milestone, so that it is available in those older releases of Pants. ✔️ 2.18.xSuccessfully opened #19702. Thanks again for your contributions! |
huonw
added a commit
that referenced
this pull request
Aug 29, 2023
…-pick of #19660) (#19702) Before this fix, #19654 was causing `pants ...` commands in the pants repo to explode and not work. This fixes it by silencing them in the pants repo, keying off the existing `NO_SCIE_WARNING=1` mechanism. Running scie-pants in the pants repo goes through a special bootstrap mechanism, that's bootstrapped outside the scie-pants processing on purpose. This in particular means that the scie-pants version check from #19600 / #19654 doesn't work, because it's not invoked via that mechanism. Fortunately, this can just be treated the same as the "am I running in scie-pants at all?" check, looking for the env var set by the pants repo bootstrapper. The version check has to be strict about the `SCIE_PANTS_VERSION` environment variable, and it cannot just do nothing when that's not set. The goal with this check is to help people using upgrade to scie-pants 0.9+ _before_ Pants 2.18 is released, because Pants 2.18 has a new distribution mechanism that's only supported by scie-pants 0.9+ (this is why we needed to land #19654 last minute, to be in Pants 2.17). scie-pants only sets the environment variable in version 0.9 too, so a user using scie-pants 0.8.0 will be running Pants 2.17 without setting `SCIE_PANTS_VERSION`, and so, to help them upgrade, we have to assume "doesn't exist" = "scie-pants is too old". The pants repo custom bootstrap doesn't set this env var, and hence used to fall into that trap. Co-authored-by: Huon Wilson <huon@exoflare.io>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Before this fix, #19654 was causing
pants ...commands in the pants repo to explode and not work. This fixes it by silencing them in the pants repo, keying off the existingNO_SCIE_WARNING=1mechanism.Running scie-pants in the pants repo goes through a special bootstrap mechanism, that's bootstrapped outside the scie-pants processing on purpose. This in particular means that the scie-pants version check from #19600 / #19654 doesn't work, because it's not invoked via that mechanism. Fortunately, this can just be treated the same as the "am I running in scie-pants at all?" check, looking for the env var set by the pants repo bootstrapper.
The version check has to be strict about the
SCIE_PANTS_VERSIONenvironment variable, and it cannot just do nothing when that's not set. The goal with this check is to help people using upgrade to scie-pants 0.9+ before Pants 2.18 is released, because Pants 2.18 has a new distribution mechanism that's only supported by scie-pants 0.9+ (this is why we needed to land #19654 last minute, to be in Pants 2.17). scie-pants only sets the environment variable in version 0.9 too, so a user using scie-pants 0.8.0 will be running Pants 2.17 without settingSCIE_PANTS_VERSION, and so, to help them upgrade, we have to assume "doesn't exist" = "scie-pants is too old". The pants repo custom bootstrap doesn't set this env var, and hence used to fall into that trap.