Drop Typer?

[agriyakhetarpal]

It apparently bothers downstream users for pyodide-build a lot because of its ill-defined compatibility guarantees with Click as development proceeds there; see pypa/cibuildwheel#2391

[agriyakhetarpal]

This issue is more of a proposal that asks if we can do so, and there would be two things to do here if we all say yes:

• refactor the CLI code to remove typer (also from pyodide-pack, pyodide-cli, etc.)
• • temporarily pin type in the meantime until this is done

Reasons not to say yes:

• too much churn for problems that are usually fixable by pins
• we can permanently pin CLI-based dependencies like Click and Typer instead and update them from time to time (see conversation in the upstream issue)
  • this could make it difficult for pyodide-build to be used as a library, which is contrary to what we had in mind in Add a public API method for searching cross-build environments #202, but I think it is fine to let pyodide-build be used as an application, as it currently is.

[ryanking13]

Thanks for the proposal. I am okay with droping typer. The cost of the transition won't be small, but it's mostly mechanical changes, and I think we can do it in a few weeks.

What I like about the typer is that it provides a very human-friendly interface both to the developers and users (which I prefer to using click directly), but I think it is not a big concern either.

The question I have is, will all the problems be solved if we just drop typer and use click directly? Or does using click also have a similar issue?

[agriyakhetarpal]

What I like about the typer is that it provides a very human-friendly interface both to the developers and users (which I prefer to using click directly), but I think it is not a big concern either.

Yes, I agree. To help with this, we could add some documentation/contributing instructions/short guide to add commands to the CLI, but not a lot of people are working on something like this right now.

The question I have is, will all the problems be solved if we just drop typer and use click directly? Or does using click also have a similar issue?

Yes, if we use click directly, it should work out fine – as the issue is with how typer implements its compatibility with click as click moves forward. @henryiii has also suggested that we can use argparse directly if we want to; that removes the dependency. It's more verbose of course (analogous how it's like for unittest in comparison to pytest), but I checked and I feel it can get the job done.

[ryanking13]

Yes, if we use click directly, it should work out fine – as the issue is with how typer implements its compatibility with click as click moves forward. @henryiii has also suggested that we can use argparse directly if we want to; that removes the dependency. It's more verbose of course (analogous how it's like for unittest in comparison to pytest), but I checked and I feel it can get the job done.

Let's then use click. I don't really want to deal with subcommands or plugins or the entry point works manually using argparse.

[evenharder]

@ryanking13 Could you please assign this issue to me?

[ryanking13]

@evenharder

Thanks. Assigned it to you.

This task would require a multi-step process, as there are multiple packages using typer in the Pyodide ecosystem.

I think you can start with making pyodide-cli compatible with both click and typer, and replace typer usages in downstream packages one by one.

[evenharder]

I appreciate your helpful guideline. I have ported most of the code in pyodide-cli to click, but there are a number of questions to be clarified...

1. rich_help_panel support
   It seems that current tests in pyodide-cli validates registration by checking whether "Registered by: plugin-test" is included in the help message. However, this behavior depends on Typer's panel name, which is set via rich_help_panel option. Should we directly use rich to decorate the output format instead?

2. testing support for click / typer
pyodide-cli imports typer object from plugin-test. Should we add tests for click components as well as maintaining typer tests as of now?

[ryanking13]

It seems that current tests in pyodide-cli validates registration by checking whether "Registered by: plugin-test" is included in the help message. However, this behavior depends on Typer's panel name, which is set via rich_help_panel option. Should we directly use rich to decorate the output format instead?

click provides a way to customize the help messages, so I think you can investigate those options. Rich can be used for formatting, but it's not a hard requirement.

If you feel that it is challenging to make help messages without Rich, then feel free to use it; otherwise, I would recommend trying not to use rich.

pyodide-cli imports typer object from plugin-test. Should we add tests for click components as well as maintaining typer tests as of now?

If possible, yes. I would like to support both click and typer for a smooth migration.

[ryanking13]

To be precise, I think we need "Typer app in a click app" approach.

First, we update pyodide-cli to expose click CLI, which can include downstream typer apps. Then we migrate all downstream packages from typer to click, and finally drop typer support entirely from pyodide-cli.

[evenharder]

Considering the argument we had on last Friday during OSSCA meetup, it seems inevitable to create a class derived from click.Group with a custom format_help_text to group the commands by its source just as Typer does. It's not technically hard as we can also provide a custom add_command with the additional source keyword.

That being said, as our ultimate goal is to remove Typer, I suggest to use the click interface for pyodide-cli regardless of the type (either click or Typer) which downstream provides. They seem to be mostly compatible barring rich options, and we can add Typer apps with click.add_command which is identical to Typer app in a click app.

Therefore I want to drive the PR with the following directions:

1. Replace Typer app in pyodide-cli to click

• this includes version callback, register_plugins, etc
• note that Typer app is still supported through click

2. Override click help print in order to display the source of each command
3. Add click-providing downstream package in test and check with pytest

[ryanking13]

@evenharder

Yes, sounds good to me. Thanks for summarizing the discussion we had.