-
-
Notifications
You must be signed in to change notification settings - Fork 644
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
allow plugins to provide "auxiliary" goals (and refactor BSP into backends) #20913
Conversation
6f48967
to
9aba8db
Compare
What's the use case for a plug in providing "built-in goals" rather than regular goal rules? Feels like |
I was not trying to rename |
Probably not. But we should probably carve out a ticket/discussion about this - as once this lands, BuiltIn goal becomes part of the usable public API, need docs around naming, why to use this vs |
Opened discussion: #20931 |
We've just branched for 2.22, so merging this pull request now will come out in 2.23, please move the release notes updates to |
@tdyas Just to loop back on this. From the discussion, it doesn't seem like there is any pushback to the feature - just a bike shed on Does the bike shed need to get figured out? Or is that something we can punt on? |
9aba8db
to
e50f128
Compare
I pushed my current progress on a Some points:
|
Does DaemonGoal here imply that the usage is a long-running "server-ish" mechanism? Like a BSP or LSP? Or can I still run a one-off command (e.g. |
It could still run one-off commands like the ones you suggest. Any suggestions of a better name? |
I ended up talking to the Claude AI and it gave me some nice suggestions: #20931 (reply in thread) |
Renamed to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You've got a typo in auxiliary.
s/uxillary/uxiliary/
And a couple comments still mention "daemon".
Do we want auxiliary and builtin goals to have the same precedence?
When multiple auxillary goals are presented, the first auxillary goal will be used unless there is a | ||
auxillary goal that begin with a hyphen (`-`), in which case the last such "option goal" will be | ||
prioritized. This is to support things like `./pants some-builtin-goal --help`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should auxiliary goals support --opt
"option goals"? I lean towards no to keep the exposed API simpler...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had not intended on changing the BuiltinGoal
API for AuxiliaryGoal
. I pretty much did not have to disturb any of the existing option parsing logic for this PR thankfully. While the suggestion would simplify the public API, it would entail modifying the existing logic which has been undisturbed thus far and risks introducing bugs. Thoughts?
Good question. I would expect them to be disjoint. An auxiliary goal should not be able to shadow a builtin goal. In that sense, builtin goals have precedence. |
Latest commits should fix the typo and the remaining instances of "daemon" goal in comments. |
The PR now actually invokes auxiliary goals (and proves that fact with an integration test). |
Co-authored-by: Jacob Floyd <cognifloyd@gmail.com>
The refactor in #20913 to move BSP out of the core rules (via the new `AuxiliaryGoal` support) did not move the registration of BSP-related `QueryRule`s out of the core rules. This PR remedies that oversight by moving the `QueryRule` registration to the applicable BSP backends.
Allow plugins to provide "auxiliary" goals via the newly-introduced
auxiliary_goals
function in the plugin registration module. This function returns an iterable ofAuxiliaryGoal
subclasses representing auxiliary goals which are run outside of the engine.The first user for this mechanism is the Build Server Protocol support which previously required the
experimental-bsp
goal to be aBuiltinGoal
and thus live in the Pants core rules. With the new auxiliary goal support, the BSP rules can now live in several new optional backends and not in the core rules.See related discussion in #20931.
The
BuiltinGoal
class intentionally remains for the "builtin goals" in the core like the help system.AuxiliaryGoal
uses a context class instead of function parameters likeBuiltinGoal
for itsrun
method in order to be more extensible in the future.