--show-completion / --install-completion ignore an explicitly named shell

[0xaef]

Summary

--show-completion SHELL and --install-completion SHELL can't be pointed at a shell explicitly. A shell name given after the flag is ignored, and Typer falls back to auto-detection. When detection fails (CI, containers, SHELL unset or a non-shell, IDE terminals), there's no way to say "generate the zsh script" through the public CLI. The error also prints an empty shell name.

Minimal example

# app.py
import typer

app = typer.Typer()

@app.command()
def hello() -> None:
    typer.echo("hello")

if __name__ == "__main__":
    app()

$ pip install "typer==0.27.3" shellingham
$ SHELL=/bin/false python app.py --show-completion zsh
Shell  not supported.

It's the same without shellingham installed. The zsh argument is not used, and --help shows both options as plain flags with no shell argument.

Expected

--show-completion zsh prints the zsh completion script, and --install-completion zsh installs it, regardless of what auto-detection finds. Auto-detection would apply only when no shell is named. If detection fails, the error would name what was detected and suggest passing the shell explicitly.

Why it matters

Tools that ship completion setup in installers or dotfiles, or run on hosts where detection is unreliable, end up calling typer._completion_shared.get_completion_script(...) / install(...) directly to bypass detection. That couples them to private API.

Environment

• Typer 0.27.3 (latest), Click 8.5.0, Python 3.14, macOS. Detection fails the same way on Linux with SHELL unset.

[danilablagorodniy37]

This is how the two options are wired in 0.27.3, not a detection problem on your side. In typer/completion.py, get_completion_inspect_parameters() builds --install-completion / --show-completion from _install_completion_placeholder_function, where both are plain bool flags. Their callbacks run while the options are being processed, call shellingham.detect_shell() through _get_shell_name(), print or install, and sys.exit(0), so whatever follows the flag is never looked at. When detection raises, the name stays "", which is the Shell not supported. message you got. The variant that takes a shell name, _install_completion_no_auto_placeholder_function (a Shells choice; both callbacks already handle isinstance(value, str)), is only selected when the environment variable _TYPER_COMPLETE_TEST_DISABLE_SHELL_DETECTION is set, which Typer's own test suite does.

Two ways to name the shell without importing typer._completion_shared, both checked with Typer 0.27.3 / Click 8.5:

1. Set that variable; the options then take bash|zsh|fish|powershell|pwsh and --help shows the argument:

   $ _TYPER_COMPLETE_TEST_DISABLE_SHELL_DETECTION=1 python app.py --show-completion zsh
   #compdef app.py
   ...
   $ _TYPER_COMPLETE_TEST_DISABLE_SHELL_DETECTION=1 python app.py --install-completion zsh

   The name says "TEST" and it is undocumented, so it may change; it is still the public CLI, not an import.

2. Use the completion protocol that the generated scripts themselves use. Typer keeps the Click 7 instruction order, source_<shell> / complete_<shell> (see shell_complete() in typer/completion.py), and the variable is _<PROG>_COMPLETE with - replaced by _ and upper-cased:

   $ _APP_COMPLETE=source_zsh app        # same output as --show-completion
   $ _APP_COMPLETE=source_fish app > ~/.config/fish/completions/app.fish

   This needs the installed entry point (app), not python app.py: the dot in app.py makes _APP.PY_COMPLETE an invalid variable name. No detection is involved at all, so for installers and dotfiles this is the robust option. The locations --install-completion would use are in typer/_completion_shared.py: ~/.bash_completions/<prog>.sh sourced from .bashrc, ~/.zfunc/_<prog> plus fpath+=~/.zfunc; autoload -Uz compinit; compinit in .zshrc, and ~/.config/fish/completions/<prog>.fish.

I could not find an earlier issue or discussion asking for an explicit shell argument, so a feature request seems reasonable: the callbacks already accept a string, so making the option's value optional would be a small change.