rich_utils lazy load in 0.17.0 release breaking safety usage

[KalebCoberly]

First Check

• I added a very descriptive title here.
• I used the GitHub search to find a similar question and didn't find it.
• I searched the Typer documentation, with the integrated search.
• I already searched in Google "How to X in Typer" and didn't find any information.
• I already read and followed all the tutorials in the docs and didn't find an answer.
• I already checked if it is not related to Typer but to Click.

Commit to Help

• I commit to help with one of those options 👆

Example Code

With typer>=0.17.0
>>> import typer
>>> typer.rich_utils
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'typer' has no attribute 'rich_utils'
>>>

Description

It looks like the lazy evaluation update in 0.17.0 removed rich_utils as a typer attribute. It's still an importable module, but since it's not imported in typer.__init__.py and no longer imported during main and other module imports, its incidental public membership is removed.

I get the error while using safety==3.6.0, like this: pyupio/safety#778

I can pin to typer<0.17.0 and wait to see if safety switches to explicitly importing the rich_utils submodule instead of accessing it as a member. But, I'm curious if typer intends to roll back that update or otherwise address the problem. Is this something we can anticipate?

Operating System

macOS

Operating System Details

No response

Typer Version

=0.17.0

Python Version

3.12.11

Additional Context

No response

[KalebCoberly]

Suggested fix here: pyupio/safety#778 (comment)

[KalebCoberly]

Submitted fix PR here: pyupio/safety#779

[andy-maier]

My vote on this is that submodules should always be available as attributes.
Even Python itself changed os.path into that direction many releases ago.

[svlandeg]

So the whole point of not importing rich_utils unconditionally, was to avoid the overhead of importing rich stuff that might not actually be needed (cf detailed analysis here). I think overal that's a really nice performance gain for many use-cases, but I can see the problem when downstream libraries assume all of this stuff (including the things in rich_utils itself) are imported by default. Then again, we didn't expose it in __init__.py and I would personally always import the submodule first.

I see that safety has already merged the fix. Just to be sure, I'll run this by Tiangolo quickly to see whether we want to change anything on our end.

[UPDATE]: just confirming that we don't intend to roll-back the lazy import of rich_utils, for performance reasons.