Skip to content
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

Merged
merged 23 commits into from
Aug 6, 2024

Conversation

tdyas
Copy link
Contributor

@tdyas tdyas commented May 13, 2024

Allow plugins to provide "auxiliary" goals via the newly-introduced auxiliary_goals function in the plugin registration module. This function returns an iterable of AuxiliaryGoal 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 a BuiltinGoal 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 like BuiltinGoal for its run method in order to be more extensible in the future.

@tdyas tdyas force-pushed the builtin_goals_in_plugins branch from 6f48967 to 9aba8db Compare May 13, 2024 17:12
@sureshjoshi
Copy link
Member

What's the use case for a plug in providing "built-in goals" rather than regular goal rules?

Feels like BuiltinGoal would no-longer be the correct term for these.

@tdyas
Copy link
Contributor Author

tdyas commented May 15, 2024

What's the use case for a plug in providing "built-in goals" rather than regular goal rules?

Feels like BuiltinGoal would no-longer be the correct term for these.

BuiltinGoal is probably misnamed since it is for goals which run without full option parsing (e.g., the help system). For BSPGoal, it needs to take over stdin and stdout when the Pants BSP implementation runs in "server" mode.

EarlyGoal is probably a better name.

I was not trying to rename BuiltinGoal with this PR though. Should I be?

@sureshjoshi
Copy link
Member

sureshjoshi commented May 15, 2024

I was not trying to rename BuiltinGoal with this PR though. Should I be?

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 goal_rule, etc etc blah blah.

@tdyas
Copy link
Contributor Author

tdyas commented May 15, 2024

Opened discussion: #20931

@huonw
Copy link
Contributor

huonw commented Jun 5, 2024

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 docs/notes/2.23.x.md. Thank you!

@sureshjoshi
Copy link
Member

@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 Builtin for something that a plugin provides...

Does the bike shed need to get figured out? Or is that something we can punt on?

@tdyas tdyas force-pushed the builtin_goals_in_plugins branch from 9aba8db to e50f128 Compare June 26, 2024 03:50
@tdyas
Copy link
Contributor Author

tdyas commented Jun 26, 2024

@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 Builtin for something that a plugin provides...

Does the bike shed need to get figured out? Or is that something we can punt on?

I pushed my current progress on a DaemonGoal API and retaining BuiltinGoal for the help goals. I will appreciate people's feedback.

Some points:

  1. I switched the API to use a context dataclass instead of passing in parameters. I believe this should provide better support for DaemonGoal.run implementations supporting multiple Pants versions by being able to check for attributes before accessing them if need be. It also allows us to implement complex getters on DaemonGoalContext if the need arises for compatibility reasons.
  2. I have not yet modeled passing stdin/stdout to the DaemonGoal. So for now, BSP still deals with sys.stdin / sys.stdout.

@sureshjoshi
Copy link
Member

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. pants plugin init --foo --bar or pants migrate --from 2.17 --to 2.21) - both of which might need to happen before goal_rule?

@tdyas
Copy link
Contributor Author

tdyas commented Jul 24, 2024

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. pants plugin init --foo --bar or pants migrate --from 2.17 --to 2.21) - both of which might need to happen before goal_rule?

It could still run one-off commands like the ones you suggest. DaemonGoal is what I thought had been suggested in the GitHub discussion; although I see you made this point in #20931 (reply in thread).

Any suggestions of a better name?

@tdyas
Copy link
Contributor Author

tdyas commented Jul 24, 2024

I ended up talking to the Claude AI and it gave me some nice suggestions: #20931 (reply in thread)

@tdyas
Copy link
Contributor Author

tdyas commented Jul 25, 2024

Renamed to AuxillaryGoal. I liked what the AI suggested.

@tdyas tdyas changed the title allow plugins to provide builtin goals and refactor BSP into backends allow plugins to provide "auxillary"goals (and refactor BSP into backends) Jul 25, 2024
@tdyas tdyas marked this pull request as ready for review July 25, 2024 01:36
@tdyas tdyas requested review from cognifloyd and huonw July 25, 2024 01:36
@tdyas tdyas requested a review from sureshjoshi July 25, 2024 01:37
@tdyas tdyas changed the title allow plugins to provide "auxillary"goals (and refactor BSP into backends) allow plugins to provide "auxillary" goals (and refactor BSP into backends) Jul 25, 2024
Copy link
Member

@cognifloyd cognifloyd left a 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?

src/python/pants/goal/auxillary_goal.py Outdated Show resolved Hide resolved
src/python/pants/goal/auxillary_goal.py Outdated Show resolved Hide resolved
src/python/pants/goal/auxillary_goal.py Outdated Show resolved Hide resolved
Comment on lines 37 to 39
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`.
Copy link
Member

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...

Copy link
Contributor Author

@tdyas tdyas Jul 25, 2024

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?

src/python/pants/goal/auxillary_goal.py Outdated Show resolved Hide resolved
@tdyas
Copy link
Contributor Author

tdyas commented Jul 25, 2024

Do we want auxiliary and builtin goals to have the same precedence?

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.

@tdyas
Copy link
Contributor Author

tdyas commented Jul 25, 2024

Latest commits should fix the typo and the remaining instances of "daemon" goal in comments.

@kaos kaos changed the title allow plugins to provide "auxillary" goals (and refactor BSP into backends) allow plugins to provide "auxiliary" goals (and refactor BSP into backends) Jul 26, 2024
@tdyas tdyas requested a review from cognifloyd July 26, 2024 12:52
@cognifloyd cognifloyd dismissed their stale review July 26, 2024 15:22

Issues addressed

@tdyas tdyas marked this pull request as draft July 27, 2024 02:11
@tdyas tdyas marked this pull request as ready for review August 6, 2024 01:37
@tdyas
Copy link
Contributor Author

tdyas commented Aug 6, 2024

The PR now actually invokes auxiliary goals (and proves that fact with an integration test).

@tdyas tdyas requested a review from cognifloyd August 6, 2024 01:55
tdyas and others added 2 commits August 5, 2024 22:45
Co-authored-by: Jacob Floyd <cognifloyd@gmail.com>
@tdyas tdyas merged commit 0baf008 into pantsbuild:main Aug 6, 2024
25 checks passed
@tdyas tdyas deleted the builtin_goals_in_plugins branch August 6, 2024 04:37
tdyas added a commit that referenced this pull request Aug 17, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants