Thanks for the detailed review, > This is a generic problem. There are several 'mailman' subcommands > that should work as soon as the mailman package is installed.
> Bonus points for fixing it in a way that allows the 'info', 'conf', > and 'status' commands to diagnose the lack of a config file. Understood, I verified locally that the null check resolves the completion crash. I'll extend the fix further so info, conf, and status give better error messages when no config is present. > I don't see why this should be necessary. Why does the 'mailman' > utility fail so badly if there is no configuration file? Agreed. Fixing the underlying config problem properly makes the hybrid approach unnecessary. I was only looking for it, thinking of including the tab-completion for plugins. I'll drop it. > AFAIK generally > packages install extensions in some shell-specified place, and they're > automatically picked up by the user's shell. Yes, that is what I had in mind too. I was thinking about shipping completion files so they land in the correct shell-specified locations automatically on system-wide installs. For virtual environment users, mailman completion install $SHELL $FILE would handle it explicitly. > - mailman completion on|off # $SHELL should tell you which shell > - mailman completion help > and maybe > - mailman completion install $SHELL $FILE_IMPLEMENTING_COMPLETION_FOR_SHELL Okay, I will follow this interface. > generate? By that I meant outputting the bundled completion script to stdout for installation, not creating anything dynamically. A few follow-up questions: 1. Regarding plugins, static scripts won't know about commands added via ICLISubCommand. Should I handle this, or is it out of scope? 2. Regarding mailmanweb, I ran mailman-web help and I think it's Django's command system underneath, and Django has built-in tab completion. Should I document the existing completion for that rather than implementing anything new? 3. Using mailman completion on, does this permanently install completions or just activate them for the current session? Thanks Sambodhi On Tue, Mar 17, 2026 at 11:09 PM Stephen J. Turnbull <[email protected]> wrote: > > Sambodhi Roy via Mailman-Developers writes: > > > 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. > > This is a generic problem. There are several 'mailman' subcommands > that should work as soon the mailman package is installed. > > Bonus points for fixing it in a way that allows the 'info', 'conf', > and 'status' commands to diagnose the lack of a config file. > > > 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. > > I don't see how this could require enough effort to justify a GSoC > internship. > > > 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. > > Currently requires a valid configuration file, but completions should > not require a valid configuration file. And 'mailman' subcommands > should not require a valid configuration file to report that as a > problem. Many of them should do something useful if there is no > configuration file. > > Please see if the simple null check seems to be able to resolve the > command completion problem. If it does, we can negotiate whether you > should do the "all commands should do something useful if there is no > configuration file" part ("useful" <= what the command is designed to > do; a helpful diagnostic is often the best you can practically do). > > > 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. > > I don't see why this should be necessary. Why does the 'mailman' > utility fail so badly if there is no configuration file? > > > 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? > > I'm not aware of completions if I use them (I use file and directory > path completions extensively, but other completions, haven't noticed > those). Whatever other packages (and/or widely used distros -- > Debian, Ubuntu, RedHat/Fedora, sorry NixOS) do. AFAIK generally > packages install extensions in some shell-specified place, and they're > automatically picked up by the user's shell. > > > 2. Completion helper command > > > > Would it make sense to include a helper subcommand such as: > > > > mailman completions --shell bash > > mailman completions --shell bash --install > > For completions to work at all, they have to be installed in a > particular way in a particular place for each shell. It's not > mailman's choice which shell is being used to invoke 'mailman'. So I > don't see how the above UI makes sense. Seems to me > > - mailman completion on|off # $SHELL should tell you which shell > - mailman completion help > > and maybe > > - mailman completion install $SHELL $FILE_IMPLEMENTING_COMPLETION_FOR_SHELL > > > to generate completion scripts > > generate? > > > 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? > > I'm not sure what you mean by "consistency similar to 'mailman'". > Completion is completion, isn't it? People who know about completion > would presumably already use Django-style completion for mailmanweb, > so I think you should stick with that unless there's some advantage to > a mailmanweb-specific completion wrapper. > > > 4. Testing approach > > > > For testing the completion scripts, I was considering: > > bats for Bash completion tests > > pytest + subprocess for testing zsh completions > > I would stick to pytest. Don't make maintainers learn new technologies. > > > 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. > > The obvious extension is to fix the configuration file mess. :-) > Django basically requires a specification for the settings.py, nothing > to fix there. But Mailman core has a search path which can cause a > lot of confusion (and in particular if it doesn't find a configuration > file, it will create one in a path that takes precedence over > /etc/mailman3/mailman.cfg, or it used to, I guess I should check). > > Steve > > -- > GNU Mailman consultant (installation, migration, customization) > Sirius Open Source https://www.siriusopensource.com/ > Software systems consulting in Europe, North America, and Japan _______________________________________________ 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
