Depends on D8385. Changes the local compute log manager to implement
the CapturedLogManager interface, using multiple inheritance.
does this need to impl both? since this is in the core package it should trigger only the new behavior right?
whats up here?
early return in test seems spicy - comment at least but maybe remove? seems like a gnarly thing if it triggers unintentionally and all the tests pass
whats the thinking of having this default to true & having it configurable versus upgrading the remote compute log managers to just return False for capture by step
It doesn't need to implement both, but I'm wary of folks who've built their own implementation on top of the ComputeLogManager methods. Might make sense to strip it out later, after some time with a deprecation warning?
Just not sure about the behavior change of splitting it out by process or not. I could go either way, to be honest, though.
For captures outside of a pipeline run context, we might not have a run_id supplied. os.path.join will error out if run_id is None because it's expecting a string.
Yeah, I'm just going to get rid of this