On Wed, Apr 9, 2008 at 8:27 AM, Lawrence Oluyede <[EMAIL PROTECTED]> wrote: > > On Wed, Apr 9, 2008 at 5:08 PM, Mike Orr <[EMAIL PROTECTED]> wrote: > > According to IRC yesterday, appengine doesn't allow C modules, so that > > takes out Mako, SQLAlchemy, and parts of Paste and Setuptools. So it > > will take a while to get any non-trivial Pylons app running on it. > > > > http://pylonshq.com/irclogs/%23pylons/ > > > Let's be rational about this. I haven't tried app engine yet altough I > have an account (plan to do it this weekend) > but I'm reading a lot of stuff about it. > > My bigger concern (putting aside the terms of service for a moment) > is: what's the point in porting existing libraries/frameworks and so > on > to make them work in the google infrastructure? > > Maybe I am short sighted but I guess it is too much work having two > different versions of the framework "just for Google".
You're discounting the "fun" effect: people want to see if they can accomplish it. There is no "fork" of Pylons/Mako/Paste. Merely people exploring the incompatibilities to see if the same package can be made compatible for both environments. Or conversely, to go to Google (or our man in Google, Guido), and say this restriction is really unworkable for us for X, Y, and Z reasons. Because if it's unworkable for us, it's unworkable for other Python frameworks and packages that a lot of people making websites want/need to use, which excludes Google from hosting said apps. Since they want apps on their servers, and they're Python fans just like us, they may be interested in doing something about it. Anyway, pkg_resources incompatibility will give them a bigger headache in the long run than it gives us. The problem with C libraries is a lot bigger than just Google. It frustrates users on Windows and Macintosh to no end, and many of them give up trying to install Pylons/lxml/ToscaWidgets/wxPython and go on to something else. Precompiled binaries don't always exist, are too old, hard to find, or built with the wrong C compiler or Unicode width. That's why we didn't use lxml in the WebHelpers upgrade. We looked and finally found a pure Python module that did what we need. But appengine has shown us there's a few other C dependencies to be worked around if possible (without killing the performance). Because these same problems presumably come up when porting Pylons to Jython, IronPython, PyPy, etc. And if Django can do it and Pylons can't... :( -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
