Update --resolve-local-platforms docs.

[jsirois]

These pre-dated --complete-platforms and now account for those.

[jsirois]

As noted here, these bad docs threw you off @huonw in one instance although it appears you read through these bad docs and actually used the option in combination with --complete-platform in Pants FAAS support in another instance. My brain does that all the time too.

[benjyw]

Thanks for the clarification.

Is there a way to turn off what you referred to elsewhere as "YOLO mode"? I.e., don't fall back to building on the interpreter executing pex, but require a local matching interpreter or fail fast?

[jsirois]

Filling in history 1st off:

• Attempt "cross-builds" of sdists for foreign platforms. #2075
• Support attempts to build sdists for foreign platforms. #2073

Is there a way to turn off what you referred to elsewhere as "YOLO mode"? I.e., don't fall back to building on the interpreter executing pex, but require a local matching interpreter or fail fast?

Sure, use --no-build. I will note this contradicts the Pants-internal decision made for FAAS where the combination of --complete-platform and --resolve-local-platforms is used to try to get a good result in as many situations as possible.

... I didn't read well. No. So you want --resolve-local-platforms {fail,fallback} where the current --resolve-local-platforms is --resolve-local-platforms fallback. That does not exist. Perhaps Pants could do the legwork on that one since its completely implementable in Pants as a search for a matching interpreter that fails or succeeds, and if it succeeds, uses that interpreter to run Pex. If Pants folks put in the work, discover that is actually useful and want to offload that work back into Pex, that sounds great. I've grown gunshy of implementing features for Pants though since they get adopted slowly or not at all.