#20931 allow plugins to provide early goals (i.e., the current `BuiltinGoal`) New discussion created by tdyas Context: The core rules for Pants' support of Build Server Protocol ("BSP") are always loaded because the BSP rules need to provide a

BuiltinGoal

implementation (i.e.,

BSPGoal

) so that the BSP server can take over stdin and stdout and respond to requests on them as per the BSP specification. This means loading rules (and the

experimental-bsp

goal) even if the users do not use the JVM backends which are the only (current) users of BSP. #20913 is a draft PR which splits the BSP rules out of the core rules by turning BSP into a proper Pants backend. But the BSP server still needs to register its

BuiltinGoal

implementation. The draft PR accomplishes this via a new

builtin_goals

plugin hook. This would be a new plugin API. 1. Are there alternative ways for the BSP server to take over stdin/stdout without needing to be a

BuiltinGoal

? 2. Is it acceptable to allow plugins to register

BuiltinGoal

implementations? 3. If so, maybe

BuiltinGoal

should be renamed to

EarlyGoal

which better fits what

BuiltinGoal

is actually used for? (Then the plugin hook would be

early_goals

.) Longer term (ulterior motive): I may want to write a LSP server for Pants which can run a server similar to how the BSP server operates. It would need to take over stdin/stdout just like the BSP server and likely would need to be a

BuiltinGoal

(baring some other way to implement the server). pantsbuild/pants