#17368 Formalizing the distinction between "source targets" and "binary targets" New discussion created by benjyw Context: #17345 The ticket mentions that if an

experimental_shell_command

A depends on another

experimental_shell_command

B then the sandbox for A includes all the sources of B, instead of just the output of running B. This is because we naively traverse the transitive deps looking for sources. A related situation exists with the "local dists" feature of the python backend: when a python_sources() depends on a python_distribution(), we build the distribution and make it loadable on the sys.path (this is to support building native deps locally without having to publish them before consuming them). But because we traverse transitive deps naively, the python_distribution's sources are also gathered that way, so they end up on the sys.path twice. In that case we handle this specially, via the the

LocalDistsPex.remaining_sources

field, which subtracts out the sources in the dist from the sources in the transitive deps. I think the underlying problem is that we don't formally distinguish between "source targets" and "binary targets". In this schema, "source targets" would provide files from their

sources

field to their dependents. While "binary targets" would have no

sources

field, and would provide files created by "building" them (the meaning of "building" depends on the target type), in topological order. When traversing targets looking for sources, we wouldn't traverse through "binary targets". Thoughts? pantsbuild/pants