-
-
Notifications
You must be signed in to change notification settings - Fork 664
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] [BUG] Behavior of app with single command is inconsistent if added to another app #243
Comments
This would indeed be really useful as single commands of a I also agree with you when it comes to the workaround you described and would like to add: With the workaround, the decorator |
+1 ran into the same. Also thanks for the workaround |
Just ran into this issue. I kept searching the documentation and online before I remembered to search here, and found this. It would at least be good to explicitly mention this behavior in the documentation, if not change it. |
(Disclaimer: I'm brand-new to #119 is also relevant to this. The approach by @cataerogong in this comment is similar to what I'm using. The relevant part of that comment roughly being: import child
app = typer.Typer()
if len(child.app.registered_commands) == 1:
app.command('child_name')(child.app.registered_commands[0].callback)
else:
app.add_typer(child.app, name='child_name') (Note: I haven't yet considered how run-time changes might affect this approach.) For now, I monkeypatched typer.Typer.add_typer so that it essentially does something very similar to the above (modulo how the child's name is set). Though I would prefer it if typer had, built-in, at least an option to have this kind of behavior--so that it can still be backward-compatible with how people might have come to expect add_typer() behavior for such single command sub-apps, but optionally mirror the semantics that the docs describe for single command apps in general (i.e. if the (sub-)app has only 1 command, there's no need to include the command name when executing it). (@tiangolo gives another solution here which I had already considered, but my implementation was buggin' out when I would pass e.g. an argument to the sub-app. I haven't spent enough time to see if it's a bug with my code or something else, but his alternative is probably also worth trying.) |
sorry for this +1 reply but just ran into exactly the same issue. |
Struggled with this for a while thank you for this, I would be happy for this to exist in the docs under sub-commands. |
I'm not sure whether this is a bug or a feature request. I think the behavior is not documented, so it might be a bug.
Related problem
In the docs, it says that when adding only one command to an app, 'Typer is smart enough to create a CLI application with that single function as the main CLI application, not as a command/subcommand' (no click group is created). See this example, which can be run with
python welcome.py
(leaving out the name of the commandmain
):When I add this typer app to another app, the behavior changes. I add this file:
When I run
python parent.py welcome
, I get the following output:The solution you would like
I expect the behavior of a typer app to stay consistent, no matter whether it is the top-level-app or a sub-app of another one. In the example above, I expect the output to be
Hello world!
, but in order to get that, I need to runpython parent.py welcome main
instead.Describe alternatives you've considered
There is a workaround to get the desired behavior: Replace the line
app.add_typer(welcome.app, name="welcome")
byapp.command(name="welcome")(welcome.main)
in the fileparent.py
.However, this doesn't solve the inconsistency and it's also not very flexible. As soon as a second command is added to
welcome.py
, the code needs to be changed back.The text was updated successfully, but these errors were encountered: