On Thu, Oct 15, 2009 at 9:59 AM, Matt Feifarek <matt.feifa...@gmail.com> wrote: > This process has been EXTREMELY annoying. I've spent many hours trying to > get things to work that I should have been spending working on my project. > Mostly, its my own ignorance of current magical techniques:
All of us have been annoyed. That's why it has taken us 1 1/2 years to write a simple, failsafe howto, and we're still not there yet. Philip and Ian did the original work in April 2008 which led to Appengine-Monkey and patches to get Mako and Beaker to run on GAE. I came in later to do more installation and testing. All of us have spent weeks pulling our hair out trying to get various things to work. If you just want to get going quickly with GAE, you may be better off using the mini framework that comes with it, or one of the smaller WSGI frameworks. Django has also been ported to it. (And they had similar problems to what we had, BTW.) > I still don't get setuptools. I don't understand namespace packages, or > rather their deployment. I don't get why I can't move (for example) paste, > and the Paste* items to another directory that is ON sys.path and have it be > import-able. All of my frustrations with GAE have been of this sort. First some vocabulary to make sure we're talking about the same things. A "package" is a directory under sys.path containing Python modules and an __init__.py module. It's importable. A "distribution" is a tarball or egg packaged so that it can be distributed on PyPI. Distributions thus contain packages. However, many people including me also call distributions "packages", so the term package is ambiguous. A "namespace package" is a Setuptools trick that allows multiple distributions to be installed under the same package namespace. Paste uses this so that 'paste.deploy' and 'paste.script' can be distributed seprately from 'paste', for those who want to use one but not the others. Zope used this to split the 'zope' namespace into 100+ distributions. This was necessary to make Zope pythonic and non-monolithic. So the answer to your question is, when you moved the packages, you did not keep everything in sync. Either you missed some egg-info directories or .pth files, or there were paths encoded in the egg-info files that were no longer valid. Or something like that. Easy_install and Pip do manage namespace packages differently, so the techniques for moving them would be different. It's normally easier to reinstall the packages rather than to move them. If you don't want to go to the network every time, you can build your own archive of source files and install from that. > Basically, the challenge to getting Pylons on GAE is to manage libraries. > Some need to be there for Pylons but not for GAE. Some need to be there fore > GAE by not Pylons. Some need to be both. Some need to be uploaded with the > "app", some cannot be, some simply should-not be. It's not clear when > egg-info directories need to go up to GAE, and when they are wasting space. Yes, that is all true. The answer is complicated, and we're not sure of all the details. > And one cannot simply add things to sys.path because of setuptools. And when > setuptools can't find something, I have no idea how to fix it. I wish I > could just ditch all of this stuff and manually manage sys.path, but as is, > Paste especially seems to rely on some magic to find itself. Paste, and thus Pylons, was built using Setuptools' features. At the time, Setuptools was seen as the package management solution for Python, and would eventually be added to the standard library. That didn't happen due to an ongoing controversy over Setuptools and Distutils, which you can read about in the pylons-discuss archive and web-sig archive. The Python core developers did not like Setuptools and did not use it. Some of those developers (Guido in particular) wrote Google App Engine. So, unsurprisingly, it was Setuptools-unaware. This led to the majority of problems for using Pylons on it. Basically, Pylons and Paste was written for a standard Python runtime environment (CPython and everything available in that world), and GAE is not that. > My status: I can take a stock pylons application in a virtualenv, wedge-in > the google libraries for yaml, datastore and the like, and run the app with > paster serve. If one moves the pylons-required libraries from the standard > site-packages to the GAE app's lib/python and add that location to sys.path, > you're almost there. Hacking in some ENVIRONMENT variables at boot-strap > time and you are there. I used Appengine-Monkey/Appengine-Homedir because my paramount goal was a simple install procedure I could explain to others. Those packages seemed to offer that, by automating things that would otherwise have to be done by hand. (Particularly installing virtualenv and setuptools.) But maybe starting from a stock Pylons installation and app is a better way to go? That's what your and Jason's research will help answer. -- Mike Orr <sluggos...@gmail.com> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
