mailcap is deprecated in Python 3.11 and will be removed in 3.13

[chayleaf]

Is your feature request related to a problem? Please describe.
See Python docs - mailcap module is deprecated

Describe the solution you'd like
Writing a custom mailcap file loader that doesn't rely on the standard library is a good solution. Additionally, I think a non-standard extension of loading mailcap from alot config dir or $XDG_CONFIG_DIR/mailcap would be a good idea.

Describe alternatives you've considered

1. Ditching mailcap files completely, opting for a mix of custom config (e.g. for html viewing) and mime associations (for opening files) and breaking backwards compatibility
2. Telling users to stay at Python 3.12 till the end of time

[pazz]

Unfortunately it seems you are right :D
Writing a custom viewer sounds like the least attractive option to me. We could just ship a copy of the latest mailcap module or indeed, use a local mapping instead of mailcaps. In the end this mainly requires a handler for html messages and a call to xdg-open for opening attachments..

[jelly]

FYI: Python 3.13 is about to be released this week

[mjg]

Here we are, Fedora 41 is released with python 3.13, and alot breaks with:

ModuleNotFoundError: No module named 'mailcap'

Now, I'm not sure this project is still alive. But just to help others gain some time before switching: copying mailcap.py from your python 3.12 installation to your local python 3.13 sitepath and commenting out warnings._deprecated(...) is enough to make alot run again, for now.

The python docs suggest the mimetypes module as a replacement for mailcap. I guess that's the "monty" in python, some form of humour. But what do I know - I'm German.

[jelly]

Alternatively one can depend on https://pypi.org/project/standard-mailcap/ for the time being.

[pazz]

Thanks for pushing this issue. ATM I agree that adding a dependency as suggested would be the cleanest and straightforward solution and I am happy to push a PR that implements this.
Long run, still, I would hope that there remains a separate mailcap library that we can depend on as it seems rather silly to replicate the code here and I am also not a massive fan of breaking the configurations by moving away from mailcap. But I am open to suggestions.