I'd actually suggest breaking out other parts that are updated more frequently, or could be used independently of TurboGears. Like Catwalk, which was actually separate to begin with. I can understand the desire to package it with TG for a full-blown system, but I don't see any other benefit that was gained by tying a separate application into a framework.
With Pylons, we've already gone for this approach, which lets us have a very stable core while extending it through WSGI middleware and libraries. Both of which don't really rely on Pylons even, so they're re-usable in other setups. There's a big caveat though that we've run into. First, I'd advise against using a setuptools namespace package. It's caused more than a few headaches in installation and dependencies with Paste, so I'd consider it a last resort type of thing. Second, the more dependencies you have, the greater the risk of a failed install due to either setuptools not being able to find the package, or the package disappearing (guess that's the same). In our case, we went with a backup option of having every single egg we use on a download page as a last resort should some package somewhere in the dependency chain not get properly installed. Alternatively, when relying on such a conglomerate of packages, the risk of a single package somewhere in the chain getting a backwards incompatible patch applied, or some other feature change you relied on; becomes a very real risk. The download page alleviates this as well by providing a source for all the egg's known to result in a working system. Cheers, Ben --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~----------~----~----~----~------~----~------~--~---
