> Of course, Red Hat is merely an aggregator of software, so in a certain > sense it doesn't matter what they choose to package with each Python > version.
True. > It would be worth notifying Red Hat of this significant > oversight in the usability of their Python 2.2 suite, however. I'll file a bug report. > I deal with the RPM/DEB availability problem by compiling it all myself. <snip> Thanks for those scripts. I had to run away and cower the last time I tried to compile Python from scratch. It was rough enough that it drove me away from even trying mod_python (which requires a threadless installation). > That's a general problem for Python applications requiring third-party > packages, and not something Webware can necessarily solve on its > own. Fair enough. Then I would suggest that the MiddleKit QuickStart docs indicate that you may need to download mxDateTime, show you how to check for its presence, and show you where to download it and install it. Or alternatively, main.py should it rewritten to only use the standard Python library. The latter sounds like a much better idea to me. > It's a tradeoff because the desires are mutually exclusive. Of > course, it's also possible that a package's license might not allow > us to bundle it. Yeah, and unless Webware gains an overeager packaging manager, I wonder whether it's worth covering all those bases. > I actually like the Zope idea of bundling a preconfigured version of > Python. Even though it looks like a waste of disk space and memory, > it's valuable because it it insulates Zope from the version of Python > and packages installed system-wide. Otherwise Zope would break if I > install an incompatible version of Python or delete some packages > Zope depends on, and this installation of Zope is "maintenance only", > meaning we don't upgrade it unless we have to. Perhaps in the future > when we have "batteries included" versions of Webware, we can package a > version with its own Python. This sounds like a good idea. Perl is a good example of why this practice is often the best way to go. I remember trying to upgrade my Perl install so I could use Akopia Interchange...and it ended up slightly breaking everything on my box, or at least it felt that way. What a nightmare. I think we've all seen what we might call 'fragile' servers which we're afraid to upgrade, lest something break really badly. Much better to isolate things. Whenever I install software, I try to put it in its own /usr/local or /opt directory, so I can install a new version without clobbering the old one. > As for the comment that Python 2.2 is the current version and everybody > should upgrade, as much as I agree with it in principle, it's not > practical in the real world. People have third-party applications (like > Zope or complex homegrown software) running, and they can't take the > risk that the application might break, even if the risk is small. I'm not sure who proposed that we should all upgrade to 2.2, but the fact remains that (AFAIK) Webware 0.7 _requires_ Python 2.2, so it's gotta get on your box somehow. RedHat decided to leave 1.5.x in place for exactly the reason you cite, and just add 2.2 beside it. Steve _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
