I have an open question on https://github.com/pantsbuild/pants/pull/10600 that I’d like answered so I finalize the PR. Namely how to expose (or not expose) retry parameters for remote execution as options.

I’ve never done that, but see

global_options.py

and the type

ExecutionOptions

. On the Python side, you would add to that class + register the global option. I don’t know how it then gets wired to Rust

let me clarify, I am aware of how to wire up the options, the question is whether we should wire them up

Ah. Generally, I would say no. Imo Pants has too many options / options fatigue Unless you expect these options to help a lot with debugging or be something people want to customize

no current need, I could foresee someone needing to adjust the timeout settings in the future but for now this will exponential backoff with a 100 millisecond slot time and up to 5 retries (thus the last retry will sleep for random amount of time equal random(0,2^5) * 100ms

I honestly don’t have any strong opinion. I agree that that default sounds reasonable.

Personally I think “number of retries” should be configurable, but I agree with @hundreds-father-404 that we have significant options fatigue. In particular, I think we should fix the fact that (effectively) all options used in Rust need to be global options - if options were better namespaced so that better/more-limited help could be given, that would be a much better place.

can do as a follow-up. is there a straight-forward way to add options scopes? just an additional

Subsystem

?

It’s generally really easy to add a new

Subsystem

, as documented in https://www.pantsbuild.org/v2.0/docs/rules-api-subsystems. The issue is that those options must be passed to Rust. They’re “bootstrap options”

well Rust could call into Python via a callback to get these sort of options

I think Stu and Greg have both looked a little into that - Stu was looking into how bootstrap options could be consumed in Rust without having to have all the performance overhead of initializing Python

the question is whether the remote execution struct needs to be initialized with the actual value or a handle that can be queried for the value later