2.0 roadmap

[dwreeves]

2.0 will likely be what comes after 1.9.

Objective for 2.0 is to release in mid 2025. That's a very, very long time away!

This is a living document. Nothing here is guaranteed, everything is subject to change.

Deprecations

Hard + immediate deprecations

These things will not be supported going into 2.0.0.

These are easy enough to enforce at the package install level, so there is no real risk of users getting hurt by this.

• Click 7 support will be dropped
• Python 3.7 support will be dropped

Hard + delayed deprecations

These things will be available in 2.0.0, and phased out entirely into 2.1.0. Using these features will trigger a DeprecationWarning.

Logic: Many of these things are already deprecated, and switching off them is relatively easy for users. These are, however, breaking API changes, and we want to support them as long as possible.

• rich_click.rich_group (use rich_click.rich_command instead)
• use_markdown=True and use_rich_markup=True (use text_markup=... instead)
• get_module_help_configuration()
• OptionHighlighter
• rich_click.cli.patch() (use rich_click.patch.patch() instead)

Soft + delayed deprecations

These things will be available in all 2.x versions, and phased out entirely in a hypothetical 3.0 or 3.1 release, if rich-click ever gets there (who knows!). Using these features will trigger a DeprecationWarning.

Logic: Switching away from these features is potentially very tedious for users, so we want to give them as much time as possible to move away.

• "command groups" and "command aliases" will go away and will be replaced with / renamed to "panels".

Features

• I want to decouple style config and non-style config somehow.
• "Styles" API: Easy configuration for styles, e.g. RichStyleConfiguration.build(primary="red", secondary="blue")

[Goldziher]

async support?

[dwreeves]

Hi @Goldziher,

If you'd like to run an async function in Click, you can do something like this:

import asyncio
import rich_click as click

async def func(a, b, c):
    ...

@click.command()
@click.argument("a")
@click.argument("b")
@click.argument("c")
def main(a, b, c):
    asyncio.run(func(a, b, c))

Or something like this, with the anyio library:

import rich_click as click
import anyio

@click.command()
@click.argument("a")
@click.argument("b")
@click.argument("c")
@anyio.run_sync
async def main(a, b, c):
    ...

Basically, if you need asynchronous code execution within the callback, creating your own event loop (recommended with asyncio, but the 2nd approach is also fine) is the way to go.

I do not believe it is in the scope of rich-click to explicitly support callbacks which are themselves async / coroutine functions. There are three reasons I do not believe we should support it:

• CLIs are by their very nature invoked synchronously by the caller as they act as the entrypoint into a system. So that is why base Click, and also Typer, and also rich-click, do not support asynchronous invocation of the callback.
• I believe that rich-click should be careful about straying too far out of scope of this library's purpose. I think rich-click should be "Click but with fancier help text." This is not to say we are religious about Click, but we also want to be careful about what we add that deviates from this scope.
• As illustrated with the examples above, running async code with Click and/or rich-click is very much doable with support from either the buitlin asyncio module or other libraries.

[Goldziher]

thanks. im already doing this. its simply pretty redundant 😉