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 environment variable help options #19078
Add environment variable help options #19078
Conversation
@@ -529,6 +536,14 @@ def load() -> TargetTypeHelpInfo: | |||
} | |||
) | |||
|
|||
env_var_to_help_info = LazyFrozenDict( |
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.
IMO this should actually be a FrozenDict
, but one can't be instantiated from OptionHelpInfo
because it contains mutable values (lists
). this feels like a deeper issue that should be dealt with elsewhere (addendum: it doesn't seem okay that LazyFrozenDict
's lazy values can be mutable?)
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.
it doesn't seem okay that
LazyFrozenDict
's lazy values can be mutable?
Good point. I've overlooked this. When fetching the value here
pants/src/python/pants/util/frozendict.py
Line 153 in cc8be36
return cast("Callable[[], V]", self._data[k])() |
it would likely be a good idea then to check it is hashable in a similar manner as is done for the values of a FrozenDict
here:
pants/src/python/pants/util/frozendict.py
Lines 99 to 102 in cc8be36
try: | |
return hash(tuple(self._data.items())) | |
except TypeError as e: | |
raise TypeError( |
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 be dealt with in a separate PR, but this will definitely break at least this PR, and possibly other code that uses LazyFrozenDict
- shall I create an issue for it?
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.
Yea, an issue would be great. I don't think that the use of the LazyFrozenDict
is very wide spread. I added it for this use case here and it might've found it's way in else where but my guess that is very limited.
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.
Thanks for this! It's very neat. I applied the diff locally and tried it out, and it looks good. I have one small nit (see below), and also a question about whether we should be calling out which subsystem the option belongs to, e.g., a line like this at the end:
Run `pants help-advanced python` to list all the options for this subsystem.
Otherwise it's hard to track this little nugget of help back to its context.
WDYT?
I'm new to the Pants ecosystem so I defer to you on how helpful this would be - at face value, at least, it does sound like a good thing to have. thanks for the suggestion! this will require a small rewrite, though, because an |
That sounds probably correct, but not something I want to drag you through right now, since it's more involved than I had anticipated. We can always do it as a followup. So I think we can merge this as-is, and I'll ask you to create an issue for the followup. |
After I merge #19099 I recommend that you merge it into your branch and push, and then CI on this PR is much more likely to pass. |
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 feels like it is duplicating already existing information in the AllHelpInfo
which is already huge.
Was there a reason to not extract this information from current data as suggested in #17618 (comment) ?
I do realize that we may need the keys (i.e. the env var names) up front to avoid loading all the lazy data in the help printer, but that could be a slimmer version than this, where the env var name is just mapping to the option name to look up from scope_to_help_info
.
Edit: For the help printer this is not a big deal as the data is gated behind lazy loading. My concern is mostly the size of the output for pants help-all
.
@kaos could you elaborate on "extract this information from current data", please? as for why we're not mapping to the option name - because it's not possible to look it up directly except by iterating over the available options, and I am not sure about whether that would be slow (though I guess it's unlikely since there wouldn't be more than a few options). or is there something else you had in mind? |
The information is already in the scope to help info so could be picked up from there at presentation time, but as you say it is nested in several lists so no easy look up without a lot of re-arranging. My comments where merely minor efficiency concerns on the size of output for |
I've re-kicked CI to get those flaky tests passing. |
@kaos sounds good to me! didn't we agree that we'd address those issues in a separate PR, though? |
Ah yes, this right?
|
Kicking CI again. |
@kaos your thoughts on merging this? |
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 there's some edges but nothing new really, so lgtm.
Thanks @marcuslimdw !! |
Addresses #17618.