Create professional Python command-line tools using Click/Typer with rich terminal output, configuration management, interactive prompts, and distribution packaging.
## CONTEXT Command-line tools remain the primary interface for developer workflows, DevOps automation, and data processing tasks, with the 2024 Stack Overflow survey showing 87% of developers use CLI tools daily. Python is the second most popular language for building CLIs after Bash, offering superior error handling, testability, and cross-platform compatibility. The Click library alone has over 500 million PyPI downloads, while Typer, built on top of Click with type hint integration, is the fastest-growing CLI framework in the Python ecosystem. Yet many Python CLIs suffer from poor error messages, missing progress indicators, inconsistent output formatting, and difficult installation processes that frustrate users. ## ROLE Act as a senior developer tools engineer with 11 years of experience building command-line tools used by thousands of developers daily. You have created CLIs for infrastructure provisioning, database migration, code generation, and deployment automation at companies like Stripe, Vercel, and HashiCorp. You maintain multiple open-source CLI tools with 10K+ GitHub stars collectively, and have deep expertise in terminal UX design, cross-platform compatibility, and Python packaging for distribution. You understand that a CLI tool is a product and applies the same UX rigor as a graphical interface. ## RESPONSE GUIDELINES - Build the CLI using Typer for type-annotated commands or Click for maximum flexibility, with Rich library integration for beautiful terminal output - Implement a hierarchical configuration system loading from defaults, config files, environment variables, and command-line flags with clear precedence - Include progress bars, spinners, and formatted tables for long-running operations and data display - Design error messages that explain what went wrong, why, and what the user should do to fix it - Do NOT print raw tracebacks to end users when a friendly error message with --verbose debug output is more appropriate - Do NOT ignore terminal width and color support detection when formatting output for different environments ## TASK CRITERIA 1. **Command Structure** -- Design a multi-command CLI with logical command groups, shared options using Click context or Typer callback, help text for every command and option, and shell completion generation for bash, zsh, and fish 2. **Rich Terminal Output** -- Integrate Rich library for formatted tables with column alignment, syntax-highlighted code output, progress bars with ETA for batch operations, styled panels for important messages, and tree views for hierarchical data 3. **Configuration Management** -- Implement a config system reading from TOML or YAML files in standard locations (XDG on Linux, ~/Library on macOS), environment variable overrides with a common prefix, and a config subcommand for viewing and editing settings interactively 4. **Interactive Mode** -- Add confirmation prompts for destructive operations using rich.prompt, multi-select menus for batch operations, password input with masking, and an interactive REPL mode with command history using prompt_toolkit 5. **Error Handling** -- Create a custom exception hierarchy with user-facing error classes that include suggestion text, wrap unexpected errors with context-preserving messages, and provide a --debug flag that shows full tracebacks and enables verbose logging 6. **Testing** -- Write tests using Click CliRunner or Typer testing utilities for invoking commands programmatically, capture and assert on stdout and stderr output, test error conditions and exit codes, and use snapshot testing for complex output formatting 7. **Packaging and Distribution** -- Configure pyproject.toml with console_scripts entry points, create a Homebrew formula for macOS distribution, set up PyInstaller or Nuitka for standalone binary builds, and publish to PyPI with automated releases 8. **Plugin Architecture** -- Design an extensibility system using entry_points for third-party plugins, define a plugin interface with abstract base classes, and implement plugin discovery and loading with graceful handling of incompatible plugins ## INFORMATION ABOUT ME - My CLI purpose: [INSERT YOUR TOOL'S PURPOSE, e.g., database migration helper, infrastructure provisioner, code scaffolding generator] - My target users: [INSERT YOUR AUDIENCE, e.g., backend developers, DevOps engineers, data analysts, non-technical users] - My command structure: [INSERT YOUR COMMANDS, e.g., init, run, deploy, status, config] - My output format needs: [INSERT YOUR FORMAT, e.g., tables for listing, JSON for scripting, colored text for status] - My distribution method: [INSERT YOUR DISTRIBUTION, e.g., PyPI package, Homebrew tap, standalone binary, internal artifactory] ## RESPONSE FORMAT - Start with the complete project structure showing source layout, test directory, and configuration files - Present the main CLI entry point with command group registration and global options - Show each command implementation as a separate module with full Rich formatting integration - Include test files with CliRunner examples covering happy paths, error cases, and output assertions - End with packaging configuration, release workflow, and installation instructions for each distribution method
Or press ⌘C to copy