How "output groups" are different from custom providers?

[Konstantin]

I noticed that in a big set of rules I oversee output groups and custom providers are used more or less interchangeably - as a custom named struct which the rule can return. This makes me wonder what are the important differences between those and which scenarios warrant using one or another.

I am aware that output groups (contrary to custom providers) can be requested (or not requested) from the command line, but frankly even that feature has questionable usability IMHO. 

What else?

Konstantin 

[Konstantin]

Thinking about it - output groups looks a bit more versatile simply because on the "receiving" end the rule can find out (using "dir") what output groups are available from each dependency and act accordingly, for instance implement "passthrough" (passing everything to the output). I'm not sure if this would require to explicitly request all the custom output groups from the command line. I hope not. 

Custom providers on the other hand can only be checked for presence, but there is no way to discover all providers coming from a dependency, which makes them slightly less usable.

[Keith Smiley]

There are at least 2 cases where I've found output groups to be quite helpful. 1 is producing debug info sidecar files like dSYMs on macOS, by building a target with `bazel build foo` you can just produce `foo`, but with `bazel build foo --output_groups=+dsym` you now also get the dSYMs. Theoretically in this case you could do the same with `bazel build foo foo.dSYM` or something similar to explicitly request another file, but I think the more generic approach is preferred.

Another nice thing is filegroup's custom support for these https://docs.bazel.build/versions/main/be/general.html#filegroup.output_group this can make it easy to take a file from a specific output group as a dependency of another rule. There's an example of this in https://github.com/envoyproxy/envoy-mobile/pull/2047

[Konstantin]

Yes, I agree that " output_groups=+dsym" is convenient and support for output groups in filegroup rule is convenient too.

But then why do we even need custom providers? Why can't everything be done using output groups?

[Keith Smiley]

Custom providers can be used for many things besides files when propagating between different rules

--
Keith Smiley

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/bf2ab7b6-d898-4a58-9231-b97b5e007948n%40googlegroups.com.

[Alex Humesky]

The output group provider is also treated specially in some cases, like for validation actions:

https://cs.opensource.google/bazel/bazel/+/master:src/main/java/com/google/devtools/build/lib/analysis/RuleConfiguredTargetBuilder.java;l=126-159;drc=6263005cdc0b1d19735215981d13c0426fb12aa9

The way I think of this is "how do you tell bazel which files in a target to build". There are a few (sometimes overlapping) mechanisms:

1. DefaultInfo(files=...) -- These are the files that are built when a target is named on the command line

2. Implicit outputs -- These are additional files from a target that can be named on the command line or used in dependencies (e.g. the _deploy.jar output of java_binary)

3. Output groups -- This is how you can ask for a whole class of outputs to be built in addition to the normal outputs (e.g. the dSYMs mentioned above, source jars for java targets)

That output groups is a provider seems more like an implementation detail. And as Keith said, output groups can have just (nested sets / depsets of) files, whereas providers can have files, depsets, lists, strings, ints, structs, other providers

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CANw2gKPob6i%2B%2BktzihZExmLn-DNVDb7S39Fk%3DXFZa%3Dr5%3D7FJQw%40mail.gmail.com.

[Konstantin]

--  Custom providers can be used for many things besides files when propagating between different rules

Oh, that's major consideration and not immediately obvious one! Thank you, Keith!