On Apr 27, 2009, at 3:01 PM, Mike Orr wrote:
At PyCon, some of us experimented with a full plugin system (Zope Component Architecture) as used in repoze.BFG. It's too early to tell whether it would be feasable for a Pylons-like framework (and most of the developers are too busy to pursue it right now). But the theoretical idea would be to move some of the middleware to it, use it for part of Pylons internal configuration and environment.py, and perhaps expose it to the application developer for customization. And this may in turn allow for greater interoperability between Pylons, TG, BFG, and other external software, and simplify the configuration systems that they all use. (Deployment configuration a la development.ini would remain separate, maybe, depending on the framework developer's/application developer's desire.)
I think TG2 will likely have a working modularity system first, which is fine since it'll be based on Pylons and should apply to us too.
The key difference between Django style re-use and repoze.bfg/Zope style re-use is how much life is going to suck down the road maintaining the apps. When you consider how Django approaches it, it seems like this will be a pain unless you're a DVCS master and are sure to use it because say you have:
Site 1:
- Comments app
- Reviews app
Site 2:
- Comments app
- Reviews app
- Articles app
Technically each 'app' in Django is just a sub-dir, so if you have 2+
sites, and you make a huge set of improvements to the Reviews app,
odd's are each site project itself is in its own version repository,
each app *itself* is merely in the larger project. So it becomes a bit
of a hassle ensuring that your Reviews app is up to date on each site,
and upgrading individual app's is problematic.
TG2 wants to avoid that, and of course this is where the Zope stuff comes in, because its component architecture allows each app to be its own package, and you can just configure it inside your project, and provide controller, model, template overrides as desired.
Of course, if you have a really good VCS, like one of the DVCS's, it might not be too horrible to manage the apps the way Django does. I'd love to hear from someone who has managed 5 Django sites that share several apps between them, and how they manage feature upgrades in an individual app amongst all the sites using it, because it just doesn't strike me as being very maintainable.
As Mike mentions, we're leaning the same way as TG2 and repoze.bfg, and using one or two small packages that have been split of from Zope which handle this stuff rather well. Not sure when it'll make its way into Pylons trunk though, as right now we're working on getting 1.0 out. Including the Zope Component Architecture and such to allow this would definitely be a bigger leap than the one to 1.0, so that might be thought of as Pylons 2.0 material (the version increase mainly just to represent the change in how you'll declare the application configuration).
Cheers, Ben
smime.p7s
Description: S/MIME cryptographic signature
