Andrew Hodgson writes:
I want to set up as a production environment, the idea is we will be getting people used to the MM3 interface and ways of working before we eventually migrate when 3.1 becomes available. I would have posted this to the users list, but recent traffic on there regarding MM 3.0 has been redirected to the dev list.
FYI, this is the kind of thing that would be perfectly reasonable and useful to post to Mailman Users. It deals with general Python, email, and OS-level knowledge and doesn't really require even knowing that Mailman 3 is a collection of three programs integrated by a REST API.
I'll deal with finding an appropriate place in the docs, no need to repost to MM Users.
My confusion relates to the virtual environment that I create. I am running from the dedicated MM3 user I created, and I am looking to expand the bundler from the user’s home directory in /home (for example). When I create the virtual environment, the files are all held in this directory, and I really want the MM3 to be installed system wide as this will be the only program running on this machine.
"System wide" doesn't really have any meaning in Unix, and especially not for pure network services. What benefits do you expect from a "system wide" installation?
Do I even need to create a virtual environment at all?
No, but it is still recommended. The basic problem is what Windows developers refer to as "DLL hell" -- different programs require different versions of the same external software. AFAIK, several of the dependencies of the Mailman 3 suite are still specified as exact versions, not "this version or later", because this helps ensure a constant environment for bug diagnosis.
From your point of view, what this means is that if you upgrade Mailman using a new virtual environment for each upgrade, you can revert to an older version simply by stopping the new version and starting the old version. (Assuming file formats don't change, of course, but at least Mailman detects those and for upgrades will upgrade them automatically.) It takes a few more minutes for each installation, but can save many hours of hair pulling downtime due to dependency conflicts at installation and mysterious bugs at runtime.
Because Mailman 3 is still evolving rapidly, I suspect you may find new versions very attractive. I would put my money on the virtual environment approach until a Mailman 3 package is available in Debian "testing" if I were you. At that point, the whole issue evaporates.
Are there any other guides relating to setting up MM3 for a purely production environment with minimal dependencies?
Probably not yet. If you decide to go that way, please do tell us about your experience. :-)
On Wed, Nov 25, 2015 at 12:00:50PM +0900, Stephen J. Turnbull wrote:
Andrew Hodgson writes:
Are there any other guides relating to setting up MM3 for a purely production environment with minimal dependencies?
Probably not yet. If you decide to go that way, please do tell us about your experience. :-)
I followed the RTD guide[1]: one thing I keep meaning to do, is add a note (via a PR) that if the installation/buildout fails with a pbr error (read your trackbacks!), a workaround is to remove the require(ments) file in mailman-bundler/eggs/pbr-1.8.1-py2.7.egg .
There's a note somewhere in the (presumed) archive of irc://irc.freenode.net#mailman from a few weeks ago, too.
[1] http://mailman-bundler.readthedocs.org/en/latest/
-- "There seems to be something wrong with our bloody ships today" -- David, Vice-Admiral Beatty (re: the Battle of the Jutland)
participants (2)
-
Adam McGreggor
-
Stephen J. Turnbull