-
-
Notifications
You must be signed in to change notification settings - Fork 646
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
Subsystems have access to the global options #10834
Comments
…er than a Param (#10827) ### Problem As described on #10062: any change to options values (including the CLI specs and passthrough args) currently completely invalidate all `@rules` that consume `Subsystem`s, because the "identities" (memoization keys) of the involved `@rules` change. As more heavy lifting has begun to depend on options, this has become more obvious and problematic. ### Solution As sketched in #10062 (comment), move to providing the `OptionsBootstrapper` (and in future, perhaps much smaller wrappers around the "args" and "env" instead) via a new uncacheable `SessionValues` intrinsic. More generally, the combination of `Params` for values that _should_ affect the identity of a `@rule`, and `SessionValues` for values that should _not_ affect the identity of a `@rule` seems to be a sufficient solution to the problem described on #6845. The vast majority of values consumed by `@rule`s should be computed from `Params`, so it's possible that the env/args will be the only values we ever provide via `SessionValues`: TBD. ### Result The case described in #10062 (comment) no longer invalidates the consumers of `Subsystem`s, and in general, only the `Subsystem`s that are affected by an option change should be invalidated in memory (although: #10834). Fixes #10062 and fixes #6845. [ci skip-build-wheels]
Fixing this will allow us to more robustly fix #10950. Right now, the fix is broken for subscopes. That's fine for now because we don't have them yet in 2.x, but a better fix would be for |
Copying some info I posted in slack: Fixing this would be really helpful. Please and thank you! |
For background, there are two related concepts here:
I propose eliminating both of these concepts, as they are a little difficult to untwine from each other. And they add a lot of complexity both in the code and to users, for very little gain. If we do want to register a handful of options on, say, all goal options, there are other ways to do so. Thoughts? |
That would be lovely. |
Agreed, that'd be great. If we find we need to add these mechanisms back, I suggest we would want to implement it a different way anyways. |
Alright, on it... :) |
So possibly the entire concept of the scope hierarchy is no longer valid? For example, we currently check for "shadowing" - that if we have --foo on an outer scope (e.g., the global scope) we don't also have a --foo on an inner scope. But this seems unnecessary now? |
So, while |
@stuhood what are the odds that we would implement that differently if we decide to add back "scoped subsystems"? |
That's a question for Benjy I think. EDIT: One thing I can say though is that the larger the Rust implementation of this becomes, the more we will want to unify them using whichever model is most natural on the rust side: https://github.com/pantsbuild/pants/tree/main/src/rust/engine/client/src/options cc @jsirois |
Yeah, I think we would want a more deliberate way of saying "there are multiple versions of these options" than just implying it by name scoping. |
That is, we can generate multiple "copies" of the same subsystem easily, with a "base subsystem" that they can get defaults from, and give them each a scope, and the scopes may or may not form a naming hierarchy via |
pre-work for this: #12514 |
Addressed in #12519 |
Closed in #12519 |
@cognifloyd This should go out in the next 2.7.0 dev release, in about a week. |
Awesome! |
Because
Options.for_scope
includes the global options, when we instantiate aSubsystem
, it will include the global options. This causes unnecessary invalidation of@rule
s that depend onSubsystem
s when global options are changed.The text was updated successfully, but these errors were encountered: