Franklin Weng writes:
Thanks for your comments!
Thank you for following up on my queries.
As far as I know, Debian packages use the system Python and the system Django. Is that correct?
Correct.
This means that you're stuck with the Debian version of the Mailman 3 suite until they update which can be slow. Mailman 3 is now mature enough that if you're still happy with the Debian version a month after installing, you'll probably still be happy with it when Debian updates. It's a good tradeoff for the majority.
But for example mixing a "testing" Mailman with a "stable" Python is likely to end badly because we frequently upgrade required levels of dependencies. So you either have to get a Debian upgrade of Mailman of your current Debian version, or you need to move to a whole not-stable Debian system. Not a pleasant choice if you think you need new features or a bugfix *now*.
This is why we recommend the venv or other isolated installations. They allow you to upgrade the dependencies as well as the core packages without interfering with the rest of your system.
IIRC I got some errors about handling characters encoding if I don't set up charset in language.master and language.en section. But the memory is vague and I don't want to go back retesting that...
I suspect that you set up charset in .master and realized that it doesn't work because .en overrides it with ASCII, and then fixed .en. That's what happened to me.
Honestly I was totally confused by all these, and as I have said, the MM3/Django/Hyperkitty/... documents didn't help much.
Upstream documents are rarely very helpful with whole sets of large packages from distros in my experience. You install the packages, you go through a bunch of configuration screens, and you finish knowing *nothing about how anything works*. Then you need a little tweak that the configuration screens don't deal with, and you don't even have the vocabulary to grep or Google effectively. :-( Then again, I'm the kind of person who prepares to sleep by reading software manuals. ;-) But I do think you lose quite a bit of knowledge by using packages, and it's painful to find obscure details without it.
Django doesn't actually show its face much in Mailman, so Django docs are not much use even to the site admin, unless you actually hack on Mailman. The only exceptions are authentication and the template language. Authentication is just hard, with more details then the Lego set in the Lego store. The templating docs are pretty good, IMO.
The Mailman docs are in somewhat sad state. The content is actually quite comprehensive and detailed as these things go, but much of it is hard to discover. The original idea was to keep the docs in the sources, as doctests for examples and in the docs directory for exposition. These docs are more developer-oriented, obviously. Then there were several attempts to create a suite package which would require core, Postorius, and HyperKitty and streamline the setup process. The "mailman-suite" version came with a companion "mailman-suite-docs" package, which I think is now the basis for mailman.readthedocs.io aka docs.mailman3.org. However mailman-suite turned out to more trouble than it was worth, and mailman-web was developed to address the more useful approach of unifying some mailman-to-Django APIs for Postorius and HyperKitty (the django_mailman3 package) and configuration (a unified settings.py, as well as standardized top-level urls.py and views.py). Of course each of these contributed more documentation, some of it redundant, older versions left to slowly become obsolete (ie, incorrect) ....
"Someday" I'd like get the documents reorganized, eliminate as much redundancy as possible and make things more discoverable. But it's a mammoth task.
Steve