✨ Add support for typing.TypeAliasType as valid parameter type.

[zarch]

See discussion for further details and sample code.

[github-actions]

📝 Docs preview for commit e13d1d8 at: https://45f079b8.typertiangolo.pages.dev

[svlandeg]

Hi @zarch, thanks for the contribution, we appreciate it!

The CI is currently failing - could you look into that? I'll put the PR in draft in the meantime. The review process will go much smoother once the CI is green 😉

[github-actions]

📝 Docs preview for commit c97aff6 at: https://8682c9ff.typertiangolo.pages.dev

[zarch]

@svlandeg I've fixed all the CI. To properly handle the TypeAliasType I also have to update mypy version to v1.10, I don't know if this might be an issue.

The only failing check is the one using Python 3.7 (not supported), se my other PR to bump the minimum requirement to Python 3.8.
Therefore, these change should be put on queue with: 🔥 Drop support for Python 3.7

[lachaib]

Hello,

I was digging on the topic on that matter and I think this PR is incomplete:

• one of the things I'm trying to achieve is to share parameter definition across sub-commands, e.g.

type Name = Annotated[str, Argument(help="The human in front of the screen")]

@app.command()
def greet(name: Name):
      echo(f"Hello {name}")
      
@app.command()
def farewell(name: Name):
      echo(f"Good bye, {name}")

To get it working, I had to modify utils._split_annotation_from_typer_annotations to enable extraction of ParameterInfo from the type alias
(basically added a recursive call to same method with base_annotation.__value__)

• also, because it can be useful to support nested annotations under the TypeAliasType, I had to unwrap a bit further down the types before reaching get_click_type
  e.g.

from typing import Doc
from pydantic import PositiveInt, validate_call

type Name = Annotated[str, Doc("An human's full name")]
type Age = Annotated[PositiveInt, Doc("An human's age")]

type Identity = tuple[Name, Age]

@app.command()
@validate_call
def register_to_vote(user_identity: Identity):
      ...

Happy to discuss/help on this topic

[zarch]

Hi @lachaib,
Sorry for the delayed response. To help move this forward, could you please:

Share the branch/commit - Do you have a specific branch or commit with these changes that can be pushed to this branch?
Provide test coverage - Could you include unit tests that cover the additional functionalities you've implemented?

This will help ensure we can properly review and integrate your changes.
Thanks!

[lachaib]

Hi @lachaib, Sorry for the delayed response. To help move this forward, could you please:

Share the branch/commit - Do you have a specific branch or commit with these changes that can be pushed to this branch? Provide test coverage - Could you include unit tests that cover the additional functionalities you've implemented?

This will help ensure we can properly review and integrate your changes. Thanks!

Hello @zarch ,

This is not a ready-to-merge contribution but I pushed my state so that you can get inspiration and consolidate this existing pull request.

https://github.com/lachaib/typer/tree/pep695

Thanks a lot

[github-actions]

📝 Docs preview

Last commit 110972a at: https://3a314827.typertiangolo.pages.dev

[github-actions]

This pull request has a merge conflict that needs to be resolved.

[tiangolo]

Thanks for the interest and work on this! ☕

I want to implement a few big refactors and features that might solve many of these use cases.

I also need to do that before expanding the surface of what is supported with additional external PRs, because that also means I would have to keep maintaining and handling backwards compatibility for those new changes while doing those big refactors.

I have not wanted to close PRs that target the same or similar problems before I have an alternative, but then I have left many PRs open for too long, which is not useful or clear either. Sorry for that.

And then, after I make those big refactors, the problem might be solved... and if not, a bunch of conflicts will show up, so it will be better and easier to start from scratch (from the new code state).

So, I'll close this one for now to keep things clean.

For the specific use case, the best would be to document it in a new GitHub Discussion (or 👍 any existing one) with the specific problem to solve (without details of the implementation) to track the feature request.

Thank you! 🍰