> Do you never build an RPM for something your distro doesn't offer? I do, but not typically when it involves replacing an existing system packages. (An exception might be a critical security fix, but that case is rare enough.)
> then simply managed those separate packages, rendering unto the SA's > what was RHEL's, and unto our apps what was our application platform. A common enough practice, but I like to have a good reason before I commit to maintaining parallel installs. It's nice to be able to leave the sysadmin tasks to the sysadmins and the development tasks to the developers. The real world isn't usually this ideal, but when you're starting a fresh project and you have a clean slate, it's nice not to deviate much from that ideal situation. > So, in short, I'd encourage you to simply consider Python 2.4 part of > your application platform, and the system Python as merely part of the > operating system. If need be. But if I end up using mod_python, which looks like a strong possibility, it means I must also maintain that against python 2.4. If TurboGears looks like the best framework, then I'll use it, and if I must (i.e. when the project is ready for deployment, RHEL5 is not out yet), I will maintain a separate install of python 2.4 and mod_python. What I'm saying, though, is that there's a good reason that some would want to stick with python 2.3: simpler maintenance. I'm currently just in the very initial stages of evaluation though. I'm rather new to the python web framework arena and there's a lot of investigation to be done. So far I've looked more closely at albatross (but got extremely cold feet when I saw that sessions got summarily deleted upon any exception) and Django. I do quite like how URLs are handled with Django. (Is something similar possible with TG?) But I also must say the 20 Minute Wiki screencast was very nice. In addition to making me take a much closer look at TG, it also made me wish textmate was available for linux. :) Cheers, Jason.
