On Mon, Feb 16, 2009 at 8:31 PM, Bayle <[email protected]> wrote:
>
> Thanks for your help. I tried your suggestions (except for the new
> command, which I couldn't find),
This is what Ian wrote me in December. He hasn't announced it because
it hasn't been widely tested (or maybe he forgot).
"""
I've created a new script as an alternative to appengine-boot,
appengine-homedir (also in appengine-monkey). This sets up a
virtualenv, and then inside the virtualenv it creates an app/
application directory. I think it's a big improvement.
The basic usage is:
$ python2.5 appengine-homedir.py MyApplication
$ cd MyApplication
$ ./bin/pip install SomeLibrary
$ cd app
... edit code in ./myapplication/ ...
$ dev_appserver.py .
I also added some code to sitecustomize.py which will initialize the
google SDK, so you can use the database etc from the code.
"""
> I could
> probably benefit from a better understanding on what it is that the
> sequence of commands given in the cookbook is trying to do. I don't
> really understand whether or how dev_appserver makes use of modules
> installed, either in the system or in the virtualenv, and I don't
> understand how appengine-monkey works.
Look at the source of dev_appserver.py and paste-deploy.py (in your
application). Google adds several directories to sys.path for its
SDK, relative to the location of dev_appserver.py. On the production
server, these paths are built into the runtime environment.
paste-deploy.py essentially does the same thing, adding the
virtualenv's site-packages directory to sys.path. It has to add it as
a site directory (using the site module) so that .pth files in it will
be processed. Note that site and sitecustomize were mentioned in your
error messages. Another problem I've had is that normal Python will
adds zip mentioned in .pth files, while the production server didn't,
although that may have been fixed. For this and other reasons, I've
sometimes had to add egg directories and zipped eggs explicitly to
sys.path in paste-deploy.py even though Python "should have added
them" due on the .pth files.
Another problem you may encounter is that the WebOb in the SDK is too
old for Pylons 0.9.7. I delete it from the SDK; some others modify
sys.path to put the newer one before it, but that may be a problem if
App Engine has already imported it.
The system site-packages is automatically on sys.path if you didn't
use --no-site-packages or whatever the option is called. This may or
may not cause OS versions of Setuptools etc to be imported in the
development server. That could explain the /usr/lib paths appearing
in your tracebacks. The production server does not have your system
site-packages, so it won't be able to import anything from there.
The appengine-monkey module ("import appengine_monkey" in
paste-deploy.py) replaces missing modules and functions in the Python
standard library with stubs. This doesn't provide the
filesystem/network capability which is forbidden in App Engine, but it
does allow packages that merely import these modules to work.
Setuptools is the main package that needs these patches.
imp.find_module() is a different case because Setuptools not only
needs the function to exist, it needs it to work too. It works with
appengine-monkey (at least on my system) but not currently without it,
although the App Engine team has recognized it probably should.
> Also, I know that SDK 1.1.2 works for me, and not SDK 1.1.3 or
> greater, but I know that you have installed on an older SDK and then
> upgraded the SDK and it works. But I tried that, and it didn't work
> for me. Is it possible that I actually did exactly the same thing that
> you did to install, but that it didn't work for me because I am on a
> different platform? I am using Debian GNU/Linux x86_64. Is it known if
> anyone has successfully gotten SDK >1.1.3 to run on Debian using the
> cookbook instructions?
I'm using Kubuntu 8.04, which should be similar. I've also gotten at
least parts of it to work on my MacBook.
> I suspect that the modules installed in the virtualenv are not being
> used by the appserver, which is why I get errors suggesting that it is
> looking in /usr/lib.
>
> I don't really understand why the virtualenv modules WOULD be used in
> the first place, since I deactivate the virtualenv before running
> dev_appserver.py. Is dev_appserver.py supposed to be using the modules
> in the virtualenv? If so, how do I confirm that it is doing so?
You deactivate the virtualenv because it can't run on the production
servers. paste-deploy.py does the equivalent of the activate script;
that's why it modifies sys.path.
The surest way to tell which libraries it's using is to write a CGI
script that prints the current value of sys.path and
repr(pkg_resources). The repr of a module shows which directory it
was loaded from. pkg_resources is the part of setuptools that's used
by paste/pylons. Something like this:
print "Content-type: text-plain"
print
import pprint
import sys
pprint.pprint(sys.path)
try:
import pkg_resources
print repr(pkg_resources)
except ImportError:
print "pkg_resources module not found"
You can probably put this code directly into paste-deploy.py .
> If
> not, then why would "import site" fail when run on the appserver,
> because I can run "python -m site" from the commandline with no
> problems?
Because dev_appserver.py has modified the Python path, and it can be
complicated to figure out how that interacts with the virtualenv and
your system's site-packages.
>> You should not be using nonstandard libraries installed in /usr/lib,
>> because they will not be available in the server environment.
>> You'll
>> have to install Setuptools into the virtualenv.
>
> Is the appserver supposed to be using libraries from /usr/lib at all?
Only the ones that are in the Python standard library.
--
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
-~----------~----~----~----~------~----~------~--~---
