New incompatible flags disable ctx.fragments.py, ctx.fragments.bazel_py

[gregestren]

--incompatible_remove_ctx_py_fragment removes ctx.fragments.py.

--incompatible_remove_ctx_bazel_py_fragment removes ctx.fragments.bazel_py.

rules_python can use this to determine if it should read Python flags from Starlark definitions or Bazel-native:

if not hasattr(ctx.fragments, "py"):
  print("I should read Python flags from Starlark.")

For bazel-contrib/rules_python#3252.

Caveats:
This approach has the downside that it's all-or-nothing: removing an entire fragment doesn't permit partial Starlarkification. Which is hypothetically an issue if we have to keep certain flags native because of strange inner Bazel dependencies.

I think for Python this isn't a huge risk. Worst-case we can redefine the flags to restrict fragment access instead of completely removing it.

[rickeylev]

Checking ctx.fragments for an attribute SGTM in general, but what about configuration_field()? These are used during the loading phase when rules are defined. IIRC, if it references a fragment name that doesn't exist, it's an error. Similar question for the fragments = ... arg of rules.

[gregestren]

Checking ctx.fragments for an attribute SGTM in general, but what about configuration_field()? These are used during the loading phase when rules are defined. IIRC, if it references a fragment name that doesn't exist, it's an error. Similar question for the fragments = ... arg of rules.

Good call.

Where does rules_python set configuration_field?

I just see one (unaffected) ctx.fragments.coverage call and some attr_builders references I don't fully follow?

[gregestren]

Where does rules_python set configuration_field?

I just see one (unaffected) ctx.fragments.coverage call and some attr_builders references I don't fully follow?

For example, https://github.com/bazel-contrib/rules_python/pull/3280/files removed a bazel_py configuration_field reference.

[rickeylev]

Oh nice, there was just that one configuration_field() call that you removed. So that's taken care of.

What about fragments = [py|bazel_py] ? Will passing that still work? py_library.bzl, py_executable.bzl, py_runtime_pair_rule.bzl, and py_runtime_rule.bzl all specify that.

The attrs_builders and rule_builders code are just wrappers around the attr.XXX functions. e.g. attrb.LabelList is a wrapper around attr.label_list.

[gregestren]

What about fragments = [py|bazel_py] ? Will passing that still work? py_library.bzl, py_executable.bzl, py_runtime_pair_rule.bzl, and py_runtime_rule.bzl all specify that.

That's fine. I checked the Bazel code and also did some manual testing.

fragments = ["py"] just holds an unresolved string until rules try to read the fragment.

So as long as ctx.fragments.py.foo isn't called it's all good.