Re: [Mailman-Developers] Improving the archives

[A.M. Kuchling]

On Fri, Jul 20, 2007 at 11:16:19AM -0400, Barry Warsaw wrote:
> Cool.  I wonder if lurker is compatible with Python 2.5's  
> mailbox.Maildir implementation and whether the two could share the  
> maildirs.  Thanks for the information!

It had better be -- Maildir has a published specification.  If there's
an incompatibility, that would be a bug in either mailbox.py or
lurker.

--amk

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

[Mailman-Developers] Major updates to Mailman 3.0 branch

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've just merged in my 'setuptools' branch to the official Mailman 3  
branch.  This means that all the autoconf-based building cruft is  
gone, dead, and buried.  Can you say "Yay"? :)

Instead, Mailman is now a setuptools based project, which is rapidly  
becoming the standard for Python applications and libraries.  There  
are lots and lots of benefits to this change; for developers, the  
most immediate benefit is that there's no more configure/make/ 
makeinstall dance for every little change.  It means you can build a  
'development' installation of Mailman and edit and test right in  
place.  This will hugely reduce the overhead for developing the code.

Also gone are the C wrapper programs, so Mailman is now a pure Python  
application.  With the change to wsgi-based web integration, and  
maildir delivery from the MTA, we really don't need them any more.

You'll notice a bunch of other things have disappeared too, like the  
3rd party packages we were distributing in the misc/ directory.   
Instead, these are downloaded on demand from the Python Cheeseshop  
.  All the packages Mailman depends on  
live in the Cheeseshop so we don't need to distribute them any more.   
And now that we're a setuptools-based project, when you build Mailman  
(see below), these dependent packages will be automatically  
downloaded and installed as necessary.  You'll need a net connection  
for the initial build, but after that, once the packages are  
installed, you're good to go.

To prepare your existing branch for the update, start by doing a  
'make distclean' followed by a 'bzr revert'.  IMPORTANT - don't do  
this if you have uncommitted changes!  'bzr stat' should now report  
no changes.

Next, cd into your 'misc' directory and remove the following  
directories:

- - Elixir-0.3.0
- - SQLAlchemy-0.3.3
- - setuptools-0.6c3
- - zope.interface-3.3.0.1

These are the unpacked dependent packages and you don't need them any  
more (in fact, they'll get in your way now).  Next, remove any  
residual .pyc files laying around, via:

% find . -name \*.pyc -print | xargs rm

Now do your 'bzr pull' to get the latest 3.0 branch changes.  If you  
have local modifications, you'll need to do a 'bzr merge' and resolve  
any conflicts.

To see if everything's cool, pick a 'development' directory.  I  
usually use a subdirectory called 'staging' in my 3.0 working tree.   
This development directory can be anything, but then do this:

% export PYTHONPATH=

for me "" would be `pwd`/staging.  Make sure this  
directory exists.

Next do this:

% python2.5 setup.py develop --install-dir 

After churning for a bit, downloaded some stuff, etc., look in your  
staging directory.  You'll have a bin directory there with all the  
Mailman command line scripts, but all the code will remain in your  
working tree.

You can now do this to run the test suite:

% /bin/testall

You should see 72 tests passing and no failures.

Though you probably won't get very far, the way this is going to work  
in deployed installations is that you'll have to run bin/ 
make_instance to create some directories and do a few other things  
that the configure and Makefile.in's used to do.  After running that,  
you'll have an etc/mailman.cfg file that you can tweak for your  
installation.  Note that you don't need to do this for bin/testall  
because the testing infrastructure creates a temporary instance that  
it uses.

Let me now if you have any problems.
- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBRqJro3EjvBPtnXfVAQL0OgQAktryl9zYZlZrm9dC644EL2hF+FMHs50v
2JTh2w6UhULAdpj+xneKR04pEfCw6HHNult03jo6NoNjYjMmzpUycDHXj7e0RaKE
mbhMkX2v2b6d01OsMrAbAyWBTZH+2rtmjEKANd/1/+LlIdy3KlJe09m+xgNY9VsV
keEIEdVQcYc=
=J3Mq
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp