Update output_paths to be relative to input root.

[bergsieker]

This is a prospective change based on conversation at the monthly sync. We know that

1. The current spec is quite clear about output_paths being working directory-relative.
2. Making output_paths relative to the working directory was probably a mistake. Making it relative to the input root leads to clearer semantics overall.
3. Currently some implementations (correctly) implement to the spec, and others implement input root-relative semantics.
4. Changing from one semantic to the other without breaking users is difficult, especially without a visible switch in the API.

The default assumption should be that the out-of-spec implementations should be updated, but given the general opinion that the spec is suboptimal, we floated the idea of updating the spec, which would cause other implementations to have to update.

As you comment on this PR, please note if possible whether you are commenting on the idea "in abstract" or from the perspective of a particular implementation.

[EdSchouten]

From Buildbarn’s perspective: Nice! I like it! Happy to implement this.

Does this mean we’ll see a patch for Bazel to use output_paths at some point? 😉

[peterebden]

Sorry I couldn't chip in in the monthly sync, had to drop out a bit early.

From Please's perspective: we don't allow any specification of working directory for build actions (and have no particular plan to) so for us the two are always equivalent, and we have no practical objection to changing the spec.

[juergbi]

If the goal is for servers to ignore this field after a transition period, wouldn't it make more sense to have this field affect the semantics of all output_* fields such that servers can remove the old (working directory-relative) logic? Or do you expect servers to also drop support for the deprecated output_files and output_directories at that point?

[EdSchouten]

I think the reasoning is that if clients are going to be patched up to set the boolean flag, they might as well be adjusted to use output_paths. That implies that if servers drop support for the old semantics, they can drop support for output_files and output_directories at the same time.

[bergsieker]

Exactly. I suspected the appetite for patching up a field that's already deprecated would be low, and this would provide a nudge to migrate to output_paths. I'm certainly willing to reconsider that position.

[juergbi]

Having server implementations drop support for output_files and output_directories at the same time as (or earlier than) this new flag makes sense (incrementing deprecated_api_version), so no objections from me. I also see no issues from the BuildBox (BuildGrid worker) implementation perspective.

[lberki]

/cc @laszlocsomor

[tdyas]

From Pants perspective, Pants uses the (non-compliant) input root-relative behavior for output paths. No objection from us to changing the spec.

[bergsieker]

After thinking more about this, I no longer believe we should pursue it. Although it will be inconvenient for those who treated Bazel as a reference client for this issue, the spec should stand as written, and clients and servers that are out of spec should be updated.

[illicitonion]

@bergsieker Could you elaborate on why the change of opinion? Is this about sunk cost of existing implementations, an opinion on the comparative quality of the approaches, or something else?

[bergsieker]

I'd put this idea forward because it seemed unfortunate to have multiple parties jump through hoops to standardize on a spec that most agree is suboptimal. However, from the start I had a strong bias in favor of letting the spec be the standard, so we'd need a really significant reason to change it. In the absence of a clear, strong signal from a large portion of the community here, I think we should let the spec stand.

Also, getting a decision quickly was important due to internal project requirements, and it seemed unlikely that this proposal would be approved quickly.