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

Add environment variable help options #19078

Conversation

marcuslimdw
Copy link
Contributor

Addresses #17618.

@@ -529,6 +536,14 @@ def load() -> TargetTypeHelpInfo:
}
)

env_var_to_help_info = LazyFrozenDict(
Copy link
Contributor Author

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?)

Copy link
Member

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

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:

try:
return hash(tuple(self._data.items()))
except TypeError as e:
raise TypeError(

Copy link
Contributor Author

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?

Copy link
Member

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.

@marcuslimdw marcuslimdw marked this pull request as ready for review May 21, 2023 13:29
Copy link
Sponsor Contributor

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

src/python/pants/help/help_printer.py Outdated Show resolved Hide resolved
@marcuslimdw
Copy link
Contributor Author

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 OptionHelpInfo doesn't know which subsystem it comes from. I think the best solution is to modify env_var_to_help_info to map to a new dataclass that contains the parent subsystem's name and the associated OptionHelpInfo. how does that sound?

@benjyw
Copy link
Sponsor Contributor

benjyw commented May 23, 2023

this will require a small rewrite, though, because an OptionHelpInfo doesn't know which subsystem it comes from. I think the best solution is to modify env_var_to_help_info to map to a new dataclass that contains the parent subsystem's name and the associated OptionHelpInfo. how does that sound?

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.

@benjyw
Copy link
Sponsor Contributor

benjyw commented May 23, 2023

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.

Copy link
Member

@kaos kaos left a 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.

@marcuslimdw
Copy link
Contributor Author

@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?

@kaos
Copy link
Member

kaos commented May 29, 2023

@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 help-all. I'm happy to leave it as-is here for now, after addressing the feedback from Benjy.

@benjyw
Copy link
Sponsor Contributor

benjyw commented May 30, 2023

I've re-kicked CI to get those flaky tests passing.

@marcuslimdw
Copy link
Contributor Author

@kaos sounds good to me! didn't we agree that we'd address those issues in a separate PR, though?

@marcuslimdw marcuslimdw requested a review from benjyw June 20, 2023 01:12
@kaos
Copy link
Member

kaos commented Jun 20, 2023

@kaos sounds good to me! didn't we agree that we'd address those issues in a separate PR, though?

Ah yes, this right?

this will require a small rewrite, though, because an OptionHelpInfo doesn't know which subsystem it comes from. I think the best solution is to modify env_var_to_help_info to map to a new dataclass that contains the parent subsystem's name and the associated OptionHelpInfo. how does that sound?

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.

@benjyw
Copy link
Sponsor Contributor

benjyw commented Jun 20, 2023

Kicking CI again.

@benjyw
Copy link
Sponsor Contributor

benjyw commented Jun 21, 2023

@kaos your thoughts on merging this?

Copy link
Member

@kaos kaos left a 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.

@benjyw benjyw merged commit f53642d into pantsbuild:main Jun 21, 2023
24 checks passed
@benjyw
Copy link
Sponsor Contributor

benjyw commented Jun 21, 2023

Thanks @marcuslimdw !!

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.

None yet

4 participants