-
-
Notifications
You must be signed in to change notification settings - Fork 648
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
Add support for v2-only goals, and replace list with a @console_rule #6880
Add support for v2-only goals, and replace list with a @console_rule #6880
Conversation
This comment has been minimized.
This comment has been minimized.
So how does option equality work here? Presumably we only want to invalidate on changes to options with fingerprint=True, right? |
Option/value equality in the engine's graph is used for memoization in the in-memory graph only: so it's essentially only used to avoid re-running things with |
1081b02
to
29b22f9
Compare
So any option change will trigger a rebuild of the graph, but if the option change didn't happen to cause any input changes to any subprocesses, they won't re-run? |
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.
This is super exciting, great to see!
My only major point which may need discussion is about the tight coupling/overloading of subsystem with v2 goal.
Otherwise a few broken corners, a few bits of boilerplate it would be nice to remove, but looks great!
pants-plugins/src/python/internal_backend/rules_for_testing/register.py
Outdated
Show resolved
Hide resolved
pants-plugins/src/python/internal_backend/rules_for_testing/register.py
Outdated
Show resolved
Hide resolved
Correct. |
This comment has been minimized.
This comment has been minimized.
29b22f9
to
512b64f
Compare
This comment has been minimized.
This comment has been minimized.
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.
This is looking great! Thanks!
src/python/pants/engine/goal.py
Outdated
@classproperty | ||
def options_scope(cls): | ||
if not cls.name: | ||
# TODO: Would it be unnecessarily magical to have `cls.__name__.lower()` always be the name? |
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.
We'd want snake_case, rather than lower, and probably want it to be overridable? Or maybe not overridable... It is a bit magical, but it's magic I kind of like...
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 think that would be a fine default. It should probably be overridable though.
Devil's advocate: Should Goals necessarily be optionable at all? Do we want that coupling? Why not let authors define subsystems where needed?
512b64f
to
b5c99a6
Compare
This comment has been minimized.
This comment has been minimized.
d251819
to
7161ddd
Compare
This comment has been minimized.
This comment has been minimized.
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.
Looks good :) I still have a handful of questions, but a much smaller handful!
src/python/pants/backend/project_info/rules/source_file_validator.py
Outdated
Show resolved
Hide resolved
1ace292
to
e1fc575
Compare
I've added one commit on top that resolves @illicitonion's last round of concerns, and (most significantly,) applies the syntax changes from #6880 (comment) This unifies/replaces:
...with having I'm really, really happy with how that clarifies and simplifies the syntax... the one downside was that the inner |
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.
That's a really cute solution, very nice!
My only open question now is: Should exit_code
be optional (i.e. None
means "I was fine" and 0
means "Eagerly terminate with exit code 0"? I feel like allowing eager termination is probably a bad thing, but also, using exit_code
to conditionally mean "exit with this code" or "ignore this because it's a magic value" feels a little odd.
""" | ||
|
||
is_goal_cls = isinstance(output_type, type) and issubclass(output_type, Goal) | ||
if is_goal_cls == cacheable: |
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.
Can we remove the cacheable
arg, and define cacheability exactly based on whether a Goal
is returned, rather than having this check?
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.
Yes, but I think that that would make @console_rule
unnecessary, and that feels like something we should wait until #6598 to nail down.
A default exit code would probably be fine, yea... Alternatively, singletons for success and failure?
|
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 like how this turned out.
I'm of two minds on whether we need Goal.Options at all. We could just require rule authors to create whatever subsystems they need in order to provide options to their console_rules. OTOH I can see how it might be a useful idiom in practice to have an implicit options scope attached to every console_rule, and then making it easy to register options on that scope without having to explicitly define a separate subsystem with a matching scope, so I'm fine with this on balance.
Great stuff!
e1fc575
to
34c96b0
Compare
…and v2 (#7598) ### Problem In #6880, there will be two types of Goals: 1. v1 `pants.goal.goal.Goal`s, registered on a singleton 2. v2 `pants.engine.goal.Goal`s, registered as a `ScopeInfo` category via `@console_rules`. But `./pants goals` supports only the first form (via access to the singleton), and would need to dig deep into `self.context` in order to get access to the scope info (...like `./pants options` does: but that's a story for another day!). ### Solution Convert `./pants goals` into a plugin to the arg splitter, similar to `./pants help`. While the arg-splitter method is not incredibly scalable, it seems like it should be sufficiently scalable to support most of our "meta-goals". ### Result v1 and v2 Goals are supported, we have one fewer v1 Task, and #6880 is unblocked.
…onsole_rule` in order to provide help, options, and a CLI scope.
…nd dedupe scope registrations.
…ncy on a scoped `CacheSetup` instance, 2) adding a `LineOriented` mixin for `Goal`.
…duce an instance of their Goal type, and options are provided by an inner class of Goal.
…xits more uniform.
34c96b0
to
68165cd
Compare
…iledeps` (#8184) ### Problem We want to finish replacing V1 `filedeps` with V2 `fast-filedeps`. Keeping both goals around gives us added complexity, e.g. more time in CI for tests. To finish the replacement, `fast-filedeps` must first get support for `--absolute` and `--globs`. ### Solution Add support for `--absolute` and `--globs`. Also, fix and refactor the unit tests, which were skipped in #6880 and never restored. Update the integration test to mirror the V1 test. We can't yet actually drop the V1 goal yet due to two features that need to be implemented for full feature parity: 1) handling `scala_library`'s `java_sources` and 2) supporting `jvm_app`s. This PR adds failing unit tests for both those cases. Once those tests can be un-skipped, then we can drop V1.
Problem
While
@console_rule
has existed for a while now, it has not yet been possible to install a@console_rule
as the exclusive implementer of a goal like./pants list
(see #6918 and #6651). Additionally, replacing existing goals comes with a need to backwards-compatibly consume options.Solution
Run goals that are unambiguously
--v1
or--v2
without passing those flags: this means that passing the--v1
vs--v2
flags is only necessary in cases where bothv1
andv2
goals are installed. Additionally, create anengine.goal.Goal
class with an innerOptionable
instance in order to claim a CLI scope (and have options), and require one for all@console_rules
. Finally, add aConsoleRuleTestBase
class to easily unit test@console_rules
.Result
The
list
goal is now implemented as a@console_rule
, and consequently: is faster../pants help list
is unchanged due to a deprecated dependency on aCacheSetup
subsystem, and an optionalGoal
-mixin for wrapping line-oriented output around aConsole
. Fixes #6918 and fixes #6651.