Allow ctx.expand_location to skip mixing in hard-coded attributes

[rickeylev]

Description of the feature request:

Essentially, add an arg to ctx.expand_location to tell it to not mixin hard-coded attribute names. Or otherwise expose args to help control this behavior.

Today, ctx.expand_location will automatically mixin files from various attributes in LocationExpander.java. The set of attributes and the files taken from them is a bit complicated. In short, the attributes deps and tools are always mixed in; I'm not sure if srcs is or not. data isn't always mixed in, but can be, depending on what the native rule does. Depending on the attribute/settings, LocationExpander will expand to the default outputs or just the executable. In comparison, ctx.expand_location will always expand to just the default outputs, plus inherit a subset of the behavior of LocationExpander. It is really quite confusing.

None of this is documented. It's also very confusing/surprising and differs from if native code (as done with args performs expansion).

I think there's a few different options here; some ideas:

1. "add_extra_stuff=true/false" arg. This would control if LocationExpander mixins in any attributes.
2. "attrs" arg. This would control which attributes LocationExpander mixes in.
3. Add args for srcs, deps, tools, and data. This would replace LocationExpander looking up the attributes themselves so the caller can selectively include/exclude them.
4. Add "executables" arg. This would replace the logic that looks at deps/data/tools and allow the caller to specify which targets should expanded to only their executable, if available.

IMHO, the (4: executables arg) is the most appealing. It allows the caller to control the expansion while keep the API pretty minimal. It doesn't sound unreasonable for a rule to want to exclude/include targets based on some arbitrary condition.

cc @f0rmiga who would probably be interested in this, too.

What underlying problem are you trying to solve with this feature?

The underlying problem to solve is making ctx.expand_location behave more similarly to native rule expansion and with less surprising behavior.

Which operating system are you running Bazel on?

No response

What is the output of bazel info release?

No response

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

• request to document expand_location: expand_location documentation #11321
• PR to change expand_location to treat executables differently: fix: expand_location binary target inputs #16381

Any other information, logs, or outputs that you want to share?

No response

[f0rmiga]

Thanks. I'd add that this makes moving native rules to Starlark rules more easily without unexpectedly breaking current behaviours.

[f0rmiga]

Also interested in more control over expand_location: bazelbuild/rules_python#846.

[comius]

From the list of proposals #2 "attrs" arg, looks the most promising.

[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. If you think this issue is still relevant and should stay open, please post any comment here and the issue will no longer be marked as stale.

[github-actions]

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please post @bazelbuild/triage in a comment here and we'll take a look. Thanks!