How should private targets be handled?

[jfrohnhofen]

Currently private targets (i.e., targets that are private variables in BUILD.go files) cannot be used from other BUILD.go files but behave as regular targets in all other ways. Maybe it makes sense to also

• not list them as targets in dbt build
• not create an alias rule for them in the Ninja file
• not build them when running dbt build //...

[ptia]

I agree with the proposed solution. I think private targets should not be built or listed by dbt build; they should be only built if
a public target is being built and explicitly requests them as dependencies. I can think of these advantages:

• It makes more sense in Go: if I define a private variable, I don't expect it to interact with the outside unless I access it somewhere public
• It allows definition of compilation intermediates to a public target that shouldn't be accessed by other targets
• (This might be too specific, but it's the situation I came across that made me want to use private targets) Say I have a target ConditionalTarget implementing a custom rule that only builds if a certain condition is met (say a flag is set); then, currently, ConditionalTarget's dependencies need to be custom, conditional builds, even if they are as simple as cc.Library, or they'd be built even if the condition is not met, which could fail. With private targets I can leave them as private cc.Library's, include them in ConditionalTarget, and they'd only be built if ConditionalTarget is.