Hi developers, I'm currently preparing a GSoC 2026 proposal for the Shell Completions project and have been exploring the current Mailman CLI implementation. While investigating possible approaches, I came across a few points and wanted to ask for guidance before finalizing my proposal.
Mailman's CLI uses Click, and recent versions of Click provide built-in shell completion features. However, while experimenting with it I noticed that completion fails when a Mailman configuration file is not present, raising the following error: AttributeError: 'NoneType' object has no attribute 'getByCategory' A simple null check fixes it, allowing completion to fall back to core commands when no config is present. Since many Mailman commands require a configuration file but some basic commands (such as --help and --version) do not, I wanted to clarify how completion should ideally behave in such cases. I currently see three possible implementation approaches: 1. Static completions Pre-generate completion scripts and ship them with Mailman. This approach is simple and fast but may become outdated if commands change or plugins add new commands. 2. Dynamic completions The completion script calls mailman at runtime to retrieve available commands and options. This automatically supports plugins but requires a valid configuration file and may introduce some latency. 3. Hybrid approach Attempt dynamic completion first (with a timeout), and fall back to static completions if the dynamic call fails. This would allow plugin support when possible while still providing reliable completions when the configuration is unavailable. At the moment, I am leaning more toward the hybrid approach, but I would be happy to explore more about Mailman's preferred approach. I also had a few additional questions regarding scope and usability: 1. Installation Method Should shell completions be automatically enabled during installation, or should users install them manually? One idea I had was to ship the completion files with the package, display a post-install message, and provide a helper command such as: mailman completions --install 2. Completion helper command Would it make sense to include a helper subcommand such as: mailman completions --shell bash mailman completions --shell bash --install to generate completion scripts and optionally provide installation instructions? I'm wondering whether this would be useful or outside the intended scope. 3. mailmanweb CLI I noticed that mailmanweb uses Django’s manage.py, which already provides shell completion support. Would it be preferable to simply document how to use Django’s built-in completion, or should the project aim to provide a consistent wrapper similar to mailman? 4. Testing approach For testing the completion scripts, I was considering: bats for Bash completion tests pytest + subprocess for testing zsh completions Does this approach seem reasonable, or would you recommend a different testing plan? Also, the project description mentions that the work may not fill an entire summer and that additional subtasks might be added. If possible, I would really appreciate suggestions for what those tasks might be so that I can better plan the scope of my proposal. Thank you for your time and guidance. Best regards, Sambodhi _______________________________________________ Mailman-Developers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
