Allow Targets to express that fields are mutually exclusive

[Eric-Arellano]

Two times now while writing bindings for the Target API, I've encountered mutually exclusive fields. That is, if one is configured, the other should not be.

For example, platforms should not be specified at the same time as compatibility for python_binary.

--

There is no way to validate that because all validation happens at the Field level, independent of any other Field.

Almost certainly, we should have a new entry_point on Target called something like additional_validation().

[jsirois]

For example, platforms should not be specified at the same time as compatibility for python_binary.

In the context of what rule? Those two fields are definitely not mutually exclusive in the context of creating a PEX file. You can specify both directly to the Pex CLI and get a sensible result.

[Eric-Arellano]

In the context of what rule?

Sorry for my delay in replying...As discussed in #12612 (comment), agreed that Pex does not enforce --platform and --interpreter-constraint are mutually exclusive, but Pants does that.

--

Another case for this issue: With #12612, I'd like to require that lockfile is set on the pex_binary if platforms is also set. The issue sketches out "platform-aware" vs "platform-agnostic" lockfiles, and [python-setup].lockfile should (de facto?) be platform-agnostic. So, using the default won't work. You either need to turn off lockfiles or use a platform-specific lockfile.

We could enforce that in the rule, but it would be nice to use the Target API because it allows for the error to be more eager, e.g. to trigger when running ./pants dependencies ::.

[Eric-Arellano]

Another example: I'm adding script as a field to pex_binary for console script support. I want to require that either entry_point or script are set, but not both. only one of entry_point or script are set, if any.