CC @witty-crayon-22786 @happy-kitchen-89482 I've had a severely reduced capacity for Pants contributions lately. I've had 2 doctors tell me I should focus getting more sleep, so there goes my hobby time. Therefore it'll be a PoC for a while, but... pretty neat stuff 😈

The TL;DR • Client opts into a new type. For PoC it's just a tuple of `Process`s but in the future would be more granular in the info. There's tradeoffs to be made when you opt into the new type. • The

<http://cache.rs|cache.rs>

command runner is responsible for taking the batch and querying the cache for each

process

object. It collects the uncached process objects to be merged and ran-as-one (TBD on whether

<http://cache.rs|cache.rs>

or

<http://bounded.rs|bounded.rs>

does the merging-and-running. PoC has it in

bounded

) • To merge we basically just combine the input digests into one and chain all the files to append to the "core" argv • If the process was successful, store the individual process runs in the cache (TBD on the output info) • (TBD collate the uncached batch run + cached results into a final result object)

this PoC is glorious too, but not worth sacrificing your health for

On topic tho: I think one way to handle stdour/stderr is write a function passed down and called in Rust (if possible) to split/collate the output. It's brittle though because it's dependent on both tool's output decisions and verbosity levels.

See `black/rules.py`: https://github.com/thejcannon/pants/blob/57a324d90ef4cf4f05f8c27e207e00ffce00d6eb/src/python/pants/backend/python/lint/black/rules.py#L98 I have N processes which I bundle into a batch

Here's the Rust side for caching: https://github.com/thejcannon/pants/blob/57a324d90ef4cf4f05f8c27e207e00ffce00d6eb/src/rust/engine/process_execution/src/cache.rs#L128 Specifically the cache key is the process, the value is just a copy of the output from the run-with-all-files run 🙈

The strategy of "batch together" instead of "split apart" ensures I don't have to split inputs, just outputs.

the rough shape looks reasonable… the biggest question around the whole thing is just whether the user-space /

@rule

API can be simple enough to make it worthwhile, including making splitting of outputs simple… i don’t know of any linters with enough JSON output to split safely, but our built in tools like dependency extraction could probably

fwiw, we had a splitting/merging strategy for a tool in v1, and it was the biggest source of bugs in the whole system (admittedly, it was being used on a compiler, where inter-dependencies are the norm, but)

if “all of these files fail/succeed together then they will fail independently” is not a guarantee (processes are not necessarily Associative), so even caching the error code and doing no splitting will require caution

so… if there are enough usecases that can actually live within those constraints and gain some benefit, then maybe.

but as pointed out on the batching-inference ticket,

pytest

is probably not one of the ones where this is the case… tests can definitely have sideffects on one another. so would need to be disabled by default.

(not to mention the fact that it would be a huge refactor of the

test

goal)

for my part, i will continue to focus on lowering per-process overheads, because there continues to be low hanging fruit there, and fixing it allows

@rule

code to be written in a readable and cache-friendly way

(for example: getting

immutable_inputs

stable and used for PEXes would drop a lot of input overhead)

Instead of running 1000 processes to infer on 1000 files, run, say 10

And since we control the output, we can make it really easy to split