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
