-
Notifications
You must be signed in to change notification settings - Fork 34
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
Feat #89 isolation and extensibility design #92
Feat #89 isolation and extensibility design #92
Conversation
This reverts commit 78d137e.
The |
This reverts commit 8d50c17.
The `command.get_usage` method generates the usage string by writing it to a new formatter. This caused Rich to apply the styles twice.
This is amazing, thanks so much! A tonne of stuff to go through so it may take me a few days to find time to properly look at it, but on the face of it I think it looks great 🚀 |
Note - |
Yea, I hear you on the I made a fix to handle the issue I found with improper usage formatting. It looks like internally click creates a new formatter to print out the usage string, so the Rich formatting was being applied twice. Now, instead of asking click for the usage I changed that portion to call Other than that, I believe (please verify) that any other changes were only updates to configuration attributes and threading the formatter through to other functions. Perhaps, it might be worth looking at moving that functionality into the formatter itself, but the PR is large enough as is, and I didn't want to accidentally break the internals. |
|
||
def main(self, *args, standalone_mode: bool = True, **kwargs): | ||
formatter = self._formatter = RichHelpFormatter(config=self.help_config) |
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.
Not sure the formatter is worth exposing here. It's only needed in the exception handling at this point as the formatter used for help generation is created by click internally. I only exposed it as a possible convenience for users. Maybe the Rich console is enough.
r"(?P<metavar>\<[^\>]+\>)", | ||
r"(?P<usage>Usage: )", | ||
] | ||
def _get_rich_formatter(formatter: Optional[click.HelpFormatter] = None) -> RichHelpFormatter: |
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 possibly not needed since the formatter entry points are in the public functions. But, I was a bit unsure of other ways users may be using the "private-by-convention" functions in this module.
My thought was maybe someone is calling these internal functions to supplement behavior, and are calling them without the newly added formatter
argument. In that case, this should fall back to the original behavior since it will then resolve the formatter from the active click context or the module-level configuration.
Sorry for being slow on the review here. If I'm honest, much of what you've written is a bit beyond me 😅 I'm keen to merge, but it makes me nervous about maintaining the code if I don't really understand it. What do you think about being added as a collaborator on the repo to help out more long term? Then I would feel much happier to merge even though I'm out of my depth. General points:
Cheers, Phil |
Merging into a new branch so that I can continue on the final bits to get this merged 👍🏻 |
This is a large PR, and for that I apologize. I'm happy to make changes and provide additional explanation based on feedback.
The main focus of this PR is to add support for isolating Rich Click's formatting and help configuration. The design supports isolation of these components by:
HelpFormatter
classHelpConfiguration
class that doubles the current module-level settingsHelpConfiguration
to be passed into Click via the supportedcontext_settings
argument provided by the Command and Group classes.Since this package does have an established user base I attempted to maintain the module-level settings behavior to prevent any breaking changes. I also added some tests to help verify the test suite using
pytest
andpytest-cov
for test coverage. The tests are the bulk of this change as I used a snapshot-based approach to capture the input and output of the examples, and then validate their compatibility between module-level and context-level configuration.I got it a bit carried away and added a few other nuggets since they seemed closely related.
RichHelpFormatter
creates a console based on theRichHelpConfiguration
as the tight coupling between the Formatter and Click's internals make it difficult to allow the Console to be configured externally (i.e. one example is that Click expects help formatting to be buffered).RichContext
class was created to allow creation of the custom formatter.Console
andRichHelpConfiguration
properties. I thought this might make sense, but happy to remove if it might cause problems elsewhere.