I had -- I think -- volunteered do release management for 2.33 <https://github.com/pantsbuild/pants/issues/23456> I intend to cut the branch ~tomorrow. (This branch is overdue, but as I mentioned in another thread we can also cut releases "early" if that helps $HEADLINE_FEATURE get out the door on an apropriate timeline.)

Can I request that 2.33 not go out the door until github.com/pantsbuild/pants/pull/23294 is merged? We hit an actual bug in REAPI that we point fixed in 2.32.0, but we need @fast-nail-55400's real fix in 2.33.0 (or I guess forward port the 2.32.0 point fix).

fyi that PR is stacked on top of github.com/pantsbuild/pants/pull/23484 which still needs re-review. I made some cleanups based on @happy-kitchen-89482’s initial review.

shipit

reapi change landed

Does this subsume https://github.com/pantsbuild/pants/pull/23026 ?

yes

@fast-nail-55400 just because I'm paranoid, does this PR also cover the case we fixed in github.com/pantsbuild/pants/pull/23381 ?

github.com/pantsbuild/pants/pull/23484 added explicit tests for the

output_directories

behavior (using BuildBarn end-to-end). The tests intentionally fail in that PR and then pass in github.com/pantsbuild/pants/pull/23294 which has the

output_paths

fix. Maybe confirm that the regression tests cover all of the cases reported?

IIRC, the particular case was a non-default working directory and treating the entire working directory as the output. There was code that special cased using the default working directory as output directory, but not some subdirectory.

Pants

main

now has a BuildBarn end-to-end test. I'd say just add whatever testing you want (and tag me to review it).

Okay, I'll see what I can do

github.com/pantsbuild/pants/pull/23509 adds a test of having a subdirectory for the working directory and capturing with

output_directories=[""]

.