Be able to query semantic options from repository rules

[oquenchil]

I'm introducing an incompatible flag for a change to a repository rule that is under Bazel and therefore has to respect the incompatible change policy.

The change in logic has to happen in the repository rule, so I need to know there the value of the semantic option.

I ask you to please introduce a method that allows querying for these values. Even if it's just allowed from repositories that the Bazel team owns, which I believe is all that we need, since we are the ones introducing incompatible changes. Third-party repository rules don't have a reason to query these incompatible flag values.

[oquenchil]

@lberki

[lberki]

/cc @laurentlb

[aiuto]

All rule authors also have a valid use case for querying incompatible flags and other semantic options. A typical case is where you want a rule set that can work during a migration, such that it takes advantage of new behavior if present, but falls back if not. This allows you to roll out new releases of your rules ahead of the breaking Bazel release, with the assurance that user will not be required to update their use of your rules along with the Bazel release.

Related: #11164

[brandjon]

This issue affects pretty much all .bzl authors, and overlaps with requests to expose the bazel version to rule/macro logic. See also #8305 and #7428.

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[aiuto]

It's still a valid feature request. Being able to ask what features are present in this Bazel instance is incredibly useful for making rules that work across evolving bazel versions.