A while ago I wrote WPHP (or perhaps more accurately I put it together from other people's pieces) for embedding a PHP app in Python with a WSGI facade. The ultimate goal of that was actually to run specifically Wordpress under Python. So I spent some time last night doing that, and created PyWordpress. It seems to work. It's really very small, since WPHP does almost all the work. (I might implement the Paste appinstall deployment setup which would expand its scope, but I'm not sure.)
It does open up some development questions. The biggest one is that this requires modifications to the Wordpress source. Right now you just need the source plus a fixed wp-config.php. But if the appinstall stuff is implemented a new wp-admin/install.php will required. Ultimately we want to embed Wordpress in Zope with topp.zwsgi, which means that authentication will come from Zope, so the authentication routines probably will have to change to respect REMOTE_USER. Any number of other things may be added. I doubt these would be reasonable upstream changes, though maybe so (you could implement similar things with appropriate Apache configuration).
So, I have to figure out how to manage a minor fork of the Wordpress code, while also tracking upstream updates. So it looks like I have a real use for Distributed Version Control. I guess there's really just two options I'd consider: bzr (or maybe Mercurial -- it's hard for me to really distinguish them) or svk -- svk seems unremarkable except for its relation to Subversion, but I want to track a Subversion repository, so maybe it's perfect, I dunno.
FYI, bzr currently has some support for tracking subversion repositories via the foreign branch functionality for subversion.
# Andrew
You can just use SVN, why not? It's a matter of a simple script to checkout the parent repo (main WP), and merge the changes into your own branch.
# Ser
It doesn't seem that simple -- I'd have to track ongoing diffs to the main WP and apply those diffs to my local repository, with some failure mechanism when there was a conflict (where a conflict is any unappliable diff). Doable, but I'd rather not work out the details myself. Though I suppose there's probably scripts out there to do this already.
# Ian Bicking
REMOTE_USER authentication can be achieved via a WordPress plugin: http://dev.wp-plugins.org/browser/http-authentication/trunk/ It uses the WordPress user database, though, meaning you still create users in WordPress. If this is unacceptable for integration with Zope, I suggest looking at the "pluggable" functions: http://codex.wordpress.org/Pluggable_Functions Less editing of upstream source. :)
It's quite possible that there won't be much modification needed. wp-config.php in particular has to be added, because a number of files reference that filename in particular. However, extra plugins don't have to be in the Wordpress tree in particular. I haven't looked at how they are activated (maybe in wp-config.php itself?), but hopefully that process would be flexible enough for what we need. The get_user* and auth_redirect functions are mostly what we'd want to override, and they are both pluggable.
I suppose what we want to do is not very different from what wordpress.org does itself, to support fully automated installs.
# Ian Bicking
Mercurial seems to be faster. We use it for some decentralized projects and it works well! See the slides here: http://indico.cern.ch/contributionDisplay.py?contribId=29&sessionId=49&confId=44
I've been watching Bazaar closely of late, and they're putting consistent and fruitful effort into allowing people to use bzr in multiple modes of operation. I won't rattle off a list of features, because the important thing is to see if it works the way you want. But I do think bzr is the one that is most likely to fit someone's way of working, and let you work consistently with others, simply because the developers are taking ideas from many of the others and making it work seamlessly in bzr.
# Ben Finney
I'd just toss in my support for mercurial as well, I use it pretty extensively and use tailor to export it to svn and pull things in from svn and a whole variety of fancy things to keep multiple libraries in sync automatically. Working at Flock I used mercurial as it was orders of magnitude faster than svn on that gigantic tree, and had tailor pulling in changes to an hg server which I would then pull from and likewise sending my merges back upstream.
Also, like the bzr team, the hg team is very responsive and active in development.
The only question I could think of is...
Why?