Tweak DescendantAddresses so that call sites can no-op when no matches

[Eric-Arellano]

For dep inference, we need to use DescendantAddress(src_root) for every source root, but this will sometimes fail. For example, Pants has a source root 3rdparty/protobuf, but doesn't have any BUILD files in it.

We may end up wanting to change the overall CI behavior so that ./pants list :: would stop failing when no targets exist, but we do not yet want to change the CI behavior until further discussion.

So, this adds an optional field to DescendantAddresses so that call sites can determine the behavior they want.

[ci skip-rust-tests]
[ci skip-jvm-tests]

[jsirois]

This is good behavior when using the more specific : or :target

I can't see why erroring for any glob is good behavior. How about fixing : too?

[Eric-Arellano]

I can't see why erroring for any glob is good behavior. How about fixing : too?

I think the idea is that you are being specific enough that we want to yell loudly when it doesn't resolve. For example, when you put src/../utiil: instead of src/../util.

I'm happy to fix, but are you sure we want to? I bias towards keeping the error, but I do not have a strong opinion here.

[jsirois]

OK, how about side-stepping taste / precedent altogether. Presumably the motivating code uses DescendantAddress directly via Get? If so can the appropriate rule be parameterized to allow the desired behavior as determined by the call site? Not dissimilar to path glob handling.

[Eric-Arellano]

Sure. To confirm, this means that the CLI will behave the same before that it will error, but the rule can now no-op?

[jsirois]

Sure. To confirm, this means that the CLI will behave the same before that it will error, but the rule can now no-op?

Yes.

I still think having globs not fail when used on the CLI is better behvior (for some goals anyhow, like list) - but changing behavior of all goals to support an internal use case had a smell.

[Eric-Arellano]

Okay I'm stumped on how to implement this without multiple Param support (#7490).

The call site in my draft PR looks like:

await Get[Targets](AddressSpecs([DescendantAddresses(..)])

We would either need to add a second param like AddressGlobMatchErrorBehavior or add a new wrapper type like TargetsRequest so it's await Get[Targets](TargetsRequest(..)). The first isn't possible till #7490, and the second seems undesirable because it makes call sites so much more clunky.

(Note that this isn't an issue with GlobMatchErrorBehavior because that param is not specified at call sites - it's determined by the global option.)

--

So I think two paths forward to resolving my issue of the Pants repo complaining that DescendantAddresses("3rdparty/protobuf") does not match:

1. Continue with this PR.
2. Fix Pants repo, e.g. add an empty BUILD file to 3rdparty/protobuf. Dep inference is feature-gated, so this won't break things for end users.

[stuhood]

It seems like it could be a field of AddressSpecs ?

[Eric-Arellano]

Ah. Yep. I thought AddressSpecs was a Collection, but it's a normal dataclass. Thanks Stu!

[jsirois]

Ah. Yep. I thought AddressSpecs was a Collection, but it's a normal dataclass.

If that would have been true there is nothing preventing adding fields to a Collection by overriding __{init,hash,eq}__ right?

[Eric-Arellano]

If that would have been true there is nothing preventing adding fields to a Collection by overriding {init,hash,eq} right?

Correct. At that point, it should probably go back to being a normal dataclass, though.

[Eric-Arellano]

Okay, ready to go. I adding the field to DescendantAddresses, rather than AddressSpecs. The error is defined in a method of DescendantAddresses, so it is much simpler to parametrize there.