DjangoCon and learning from Zope 2. Mark Ramm presented probably the most thought-provoking talk at DjangoCon. He’s started writing it up as a series of posts.
Sign in with 
OpenID
DjangoCon and learning from Zope 2. Mark Ramm presented probably the most thought-provoking talk at DjangoCon. He’s started writing it up as a series of posts.
I was fairly non-impressed with the presentation. He mainly presses Django to use and create more independent components.
There are some interesting points about Zope and other frameworks, but this should have been a 10 minute talk instead of one hour.
If interoptability with other projects is so important, why be limited to just Python tools? Shouldn't we be looking to roll in the nice technologies coming from Java, Ruby, C# and others? The same arguments made against Django can be made against all Python web toolkits.
Oh, and he's right. easy_install makes me sick.
Pete - 18th September 2008 01:10 - #
Maybe the talk doesn't come across so well as an online video, but I think it was exactly right for the conference. Mark (and Cal) were invited because we wanted outside opinions that would tell us where we were going wrong. Mark's point that Django needs to play better with the wider Python ecosystem is a valuable one, and worth dedicating time to. I think he made a very strong case.
In well considered moderation, perhaps. I'm a TurboGears refugee. It's hard to glue things together without leaving visible cracks.
Steve Bergman - 18th September 2008 02:25 - #
As someone who came to the Python community via django(exclusively), and now considers themselves part of the django community as a whole, I have to say, I've never noticed this myself. And as far as interdependencies go, from django.conf import settings; settings.configure() makes it very easy to use pieces of django without needing to create a faux django project or settings file. The one exception to that would be the ORM(at least in terms of using syncdb and such).
Alex - 18th September 2008 05:46 - #
Where I said I considered myself part of the django community as a whole, I meant python community.
Alex - 18th September 2008 06:22 - #
Django's doing an excellent job being Pythonic. Emulating Zope would just drive everyone crazy.
(And the reason for that is that every single release of Zope has suffered from second system effects. They're *always* overdoing things, in every new revision.)
Fredrik - 18th September 2008 09:37 - #
"settings.configure() makes it very easy to use pieces of django without needing to create a faux django project or settings file"
Yeah, there are indeed more ways to get modularity than just splitting everything up in a hundred small pieces and inventing a dynamic installation system that makes sure that nobody ever knows what code they're actually running...
(but I'm biased, of course -- the use of lazy settings was my idea ;-)
Fredrik - 18th September 2008 09:44 - #
Fredrik, maybe you should just watch the presentation or read mark's post. It's not about emulating Zope, it's about learning from the history of Zope.
casseen - 18th September 2008 12:06 - #
I've read Mark's post -- which currently talks about tight coupling. And that's a great example of Zope's tendency of overdoing things, of course: they've split the Z3 core up in so many individual packages they had to develop their own packaging system to be able to install the darn thing.
Django, in contrast, is one tarball. A single SVN tree. Tons of people are just using "svn up" to grab the version they need. You're potentially wasting a few megabytes of diskspace per server installation, but who hasn't got that these days? (I just bought a couple of 750 MB disks for ~$100 each. In Sweden.)
And sure, there's some coupling in the Django code base, but Python bytecode doesn't take much space in memory, so who cares if Django's pulling in a few modules too much when you use a portion of it. I'm looking at two actively used, long-running Django servers as we speak: one currently uses 480 kilobytes of resident memory, the other is using 2196 kilobytes. Both servers are using 0.0% of the memory of the servers they are running on. That's not much to worry about, really.
So what *is* this "coupling" problem that Mark is so concerned about, really? What would reduced coupling save us? A megabyte of memory and a little diskspace? In return for tens of thousands of users who no longer know what version of the software they're actually running, since you've replaced a single SVN revision or version number with a long list of component versions.
Sure doesn't sound like good software engineering to me...
Fredrik - 18th September 2008 18:03 - #
(btw, can any Zopista perhaps explain why the latest tagged release over at svn.zope.org is a seven month old release candidate? And if we can learn something from that? ;-)
Fredrik - 18th September 2008 19:06 - #
Fredrik, I know you enjoy bashing Zope, and you can find plenty of things to bash I'm sure, but I'll answer anyway as you asked.
I don't know which Zope you looked at in our repository. Zope 2 had a release about two months ago, 2.11.1. It was tagged properly in SVN too.
For Grok, we've had a release in june and a new one coming up in a few weeks. We do have SVN tags for this too, and we still use a list of component versions for our dependencies.
Zope 3 is, as you know, split up into multiple components many of which have had recent releases. The distribution Zope 3 made out of those components has had a release candidate release last month, I believe. These have version strings too; the latest is 3.4.0c7 (and yes, they should do a final release).
Managing a project as a number of distributed components is not easy. You can argue quite successfully indeed we've gone too far and caused more problems than it was worth. We can also argue we've learned things and are now more aware of dependency structures which may help us improve things and cut away things we find we aren't really using. It allows us to recombine our packages into new frameworks like Grok and repoze.bfg.
It's frustrating we get Zope bashing after a TurboGears guy pointed out *mistakes* Zope 2 made a decade ago in a talk to a Django audience. What did we do to deserve this?
Martijn Faassen - 19th September 2008 16:12 - #
Fredrick, it's possible to use svn:externals to use "svn up" to grab the latest versions of everything of a project which is split into multiple source trees. Plone does this, since they have a long history of taking packages developed as 3rd party add-ons and integrating them into the core. Of course it's easier to track a single svn revision than a set of revisions. Neither approach is right or wrong - it's just trade-offs.
Sure, Zope 3 could have developed a simpler way of tackling the problem of re-assembling multiple source trees into a whole. But Buildout isn't *just* about solving that problem - it's about letting you say, "I'm going to have a config file which describes *all the parts required to assemble my own site* (or project)." Becoming more adept at working with projects that are a set of revisions from multiple source trees is important regardless of whether the Django devs decide to restructure the Django source or not, since the whole reusable apps approach is about assembling a site composed of "django plus django-add-on #1 plus django-add-on #2 plus djanog-add-on #3 plus plain-python #1 plus plain-python #2".
I can speak from experience that the add-on problem often starts small, you say to yourself, "I'm just going to use this one add-on - I don't even need to make a note about that, I'll just remember that I'm using it." A few more add-ons later and you decide, "I'll make an INSTALL.txt that lists the add-ons I'm using." A few more add-ons later, and a few years go by, and you've been slack with maintaining your INSTALL.txt and you have a crapload of add-ons and now you are thinking, "ug, I don't even want to go near that install for fear of knocking the whole damn ball over. I'm not even sure which add-ons I'm still depending upon and which ones are just cruft that I'm no longer using."
The coupling problem that Mark is concerned about is really more about cultural coupling than technical coupling, which as he sums up in his post, "My goal with the talk was to shake things up a bit, and hopefully to encourage lots more cross-talk and cross pollination between Django and the rest of the python web developer community." It's about a Django person being able to say, "hey, I want to use a couple Zope packages in a Django-based project" and not have the other Django people working on that project not act like someone just pissed in their cornflakes. And that last sentence applies to any combination of Django, Grok, Pylons, Turbogears, Zope, Plone, web2py, etc.
Kevin Teague - 19th September 2008 20:33 - #
I feel a little for Mark Ramm. Watching the youtube vids it's clear Cal went the safer route by injecting a fair bit of humour between jabs. That said I don't agree that Django can necessarily learn a lot from Zope as they have gone down a completely different path.
In essence I really think that the two critical areas where zope just hasn't cut through are zodb and simplicity. I can't help wonder what would have happened if zope had an orm as an alternative to the standard zodb persistence.
Also there has been some admirable work done with Grok but that should have been at the core of the migration from Zope 2 to Zope 3.
Zope has alienated a big potential developer audience by having zodb and enterprise level configuration and features at the heart, whereas Django has appealed to a much lower common demoninator.
I have written a blog post which expands on this a bit:
http://blog.haydon.id.au/2008/09/mark-ramm-django- and-learning-from-zope.html
"I'm just going to use this one add-on - I don't even need to make a note about that, I'll just remember that I'm using it."
But what professional development team works like that? Once you leave the "single guy developing on the deployment machine," chances are that both testing and deployment involves non-development servers and non-Python software and non-Python people -- not to mention existing configuration management tools and routines.
Fredrik - 25th September 2008 10:28 - #