Rich installation creates a non-uniform CLI experience

[deepyaman]

Description

Kedro 0.18.2 requires Rich, but it doesn't use Rich in the CLI. Typer 0.6.x doesn't require Rich, but it detects and uses it, if installed. This means that a plugin with a Typer CLI will look different for the part if provides, compared to the default/other plugins' CLIs.

Context

How has this bug affected you? What were you trying to accomplish?

I'm using Typer to develop a Kedro plugin, because it's compatible with Click and has some advantages (e.g. type-hint-based syntax for specifying arguments). However, I spent several hours last night figuring out how to patch Typer in my plugin so that it wouldn't use Rich to format the usage messages, since Kedro doesn't (see below).

Steps to Reproduce

1. Create a plugin. The core code can look something like:

   import click
   import typer
   
   
   @click.group(name="Kedro-Kitty")
   def commands():
       pass
   
   
   @commands.group(name="kitty")
   def kitty():
       pass
   
   
   app = typer.Typer()
   
   
   @app.command()
   def meow():
       """A single-command Typer sub app.
   
       I was too lazy to update this with ASCII art of a cat saying "meow."
       """
       print("Typer is now below Click, the Click app is the top level")
   
   
   typer_click_object = typer.main.get_command(app)
   
   kitty.add_command(typer_click_object, "meow")

2. Install it.

3. From a Kedro project, run kedro -h, kedro kitty -h, and kedro kitty meow -h

Expected Result

Tell us what should happen.

Ideally, you should have a uniform CLI.

You can achieve this by adding

import typer.core

typer.core.rich = None

under import typer, thereby monkeypatching typer to make it think Rich wasn't installed/it's import attempt resulted in an ImportError. But this is probably fragile.

Alternatively, you could just pin Typer to versions before it introduced Rich support, but that's obviously not ideal...

Other possibilities include using rich-click or Typer to use Rich uniformly through the CLI, but I'm personally not a fan of forcing a Rich CLI.

Actual Result

Tell us what happens instead.

Yes, my conda env name betrays that I'm not actually working on Kedro-Kitty. 😿

Your Environment

Include as many relevant details about the environment in which you experienced the bug:

• Kedro version used (pip show kedro or kedro -V): 0.18.2
• Python version used (python -V): 3.10.5
• Operating system and version: M1 Mac

[antonymilne]

It was our eventual plan to (at least try) to move kedro over to rich-click - see point 7 of #1464 (we won't necessarily complete these in the order written out there). As you say, this would solve the issue. Please can you explain why you don't think this would be a good idea?

At the moment I find there's a more significant non-uniformity that exists inside kedro already: log messages are styled according to rich, while the CLI uses click.secho. My proposed solution to this would again be for us to move over to rich-click.

While on the topic, I'm curious what you think of typer. Do you think we should consider moving to it? Note that we have a relatively complicated click setup with some weird custom stuff going on (e.g. enable the hierarchy kedro built in command < plugin command < project cli.py), so I'm not sure how straightforward it would be. If we do want to adopt rich on the CLI then from what you say here it seems like we'd get it for free if we used typer with no need for rich-click.

[deepyaman]

It was our eventual plan to (at least try) to move kedro over to rich-click - see point 7 of #1464 (we won't necessarily complete these in the order written out there). As you say, this would solve the issue. Please can you explain why you don't think this would be a good idea?

I'll try to remember. I was a mixture of sleep-deprived and annoyed at Rich when I wrote this. 😛

While on the topic, I'm curious what you think of typer. Do you think we should consider moving to it? Note that we have a relatively complicated click setup with some weird custom stuff going on (e.g. enable the hierarchy kedro built in command < plugin command < project cli.py), so I'm not sure how straightforward it would be. If we do want to adopt rich on the CLI then from what you say here it seems like we'd get it for free if we used typer with no need for rich-click.

I'm not sure it's straightforward, but I think it's possible. I looked into it briefly when I learned about Typer, but it looked daunting, because of some of the things you mentioned; however, you can always generate underlying Click objects from Typer and use them where necessary. If we wanted to do this, would probably do it piece by piece, again because Typer is meant to be interoperable with Click.

It would help getting rid of all those @click.option decorators at least. I think it's a bit scary to copy over, if you want to overwrite a command.

[merelcht]

Two optional solutions that have been suggested

1. Make rich optional / not a core dependency of kedro #2928
2. Consider using rich-click or typer #2210

When we start on working on Rich again, we'll need to make a decision on which solution to implement.