On Thu, Oct 15, 2009 at 2:01 PM, Matt Feifarek <[email protected]> wrote:
> On Thu, Oct 15, 2009 at 12:41 PM, Jason S. <[email protected]> wrote:
>>
>> > 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.
>>
>> When you install eggs with easy_install, it adds the egg's path to
>> easy_install.pth. If you move the egg somewhere else, it won't work
>
> That part I get. In fact, I've often modified easy_install.pth manually.
>
> But I'm using pip. And pip doesn't mess with that file, nor it seems any
> other meta-data anywhere on sys.path. But still, I couldn't move Paste*
> around.
>
> I was considering trying an install with easy_install and then
> hand-modifying easy_install.pth next.
pip will respect easy_install'd packages. So if you easy_install
something the pip install it, pip will see the easy_install'd package
and do nothing. You should be sure to use virtualenv
--no-site-packages. Also pip install --ignore-installed will force a
fresh install.
I remember at some point having a problem with pip installing the
Paste packages, and paste/__init__.py was missing. I think I was
working on an actual app so I punted and created the file manually,
and didn't try to reproduce and fix it.
Note that to get .pth files respected you can't add a directory to
sys.path, instead you have to do "import site; site.addsitedir(dir)"
which also looks for .pth files. runner.py does this; if nothing else
you should look at what runner.py does. It also goes through the
necessary steps to get rid of the system webob (or other installed
libraries) if you want to use an upgraded version. It's slightly
different on the SDK and the live environment.
>> unless it's added to the path somehow. BTW, I don't think GAE
>> uses .pth files, which is why sys.path manipulation is necessary.
>
> It seems like this isn't true. If I omit pth files when uploading to GAE, my
> app is failing with a 500 error. But I wouldn't trust that yet... can you do
> a test on your setup and see if you need or don't need the .pth files? (up
> to and including easy_install)
At one time .pth files weren't being read on GAE (or maybe
appengine-monkey messed something up, I can't remember). This hasn't
been a problem for at least the past six months, or maybe a year.
>> When you install them with pip, I think they overlap (i.e. one paste/
>> directory in site-packages/).
>
> Yes, that's true, but I don't understand why moving those directories from
> one site-packages to another should matter. I can't find whatever cruft is
> telling python to look in that and only that sys.path location for paste.
>
>
>>
>> I'm not sure what all the problems you're having with setuptools
>> entail, but my app.py *prepends* to sys.path, which works a little
>> better because it gets around installed versions of libraries in the
>> GAE environment.
>
> You mean to have the upgraded webob for example?
I found prepending alone to be insufficient in some cases, instead I
scan and remove any webob directory, in addition to prepending.
>> I use the GAE SDK instead of paster serve, because then all the GAE-
>> specific libs should be provided without moving anything. Can you use
>> datastore, etc, locally without the SDK?
>
> Yes. I simply add the path to the google libraries to sys.path; I'm running
> DataStore (well, whatever emulation that the SDK provides on my "paster
> serve development.ini" pylons app. Which means I can use the debugger,
> webtest, etc.
I don't use paster serve, and wouldn't recommend it. You can/should
use paste.deploy.loadapp('development.ini') in your main.py or
runner.py or whatever script, and then use dev_appserver.
> Can you use the debugger (weberror)?
I have gotten it to work, but by overwriting
environ['wsgi.multiprocess'] (to set it to False) -- without that the
debugger won't work. But in the SDK generally it won't be
multiprocess until you edit a file, so the debugger works fairly
reliably.
Generally, I'll note one advantage to GAE that you should make use of:
once a set of libraries is working, everything to make them work is in
a set of portable files (.py files and directories and whatnot).
After installing I check *all* the files into version control. I
don't do this elsewhere because there are C extensions and other
things that aren't portable, but GAE disallows all those so they
aren't an issue. It would be relatively easy to create an actual
tar/zip of everything for a working Pylons setup, and anyone could use
it as a starting point, and it would be 100% reliable. Unfortunately
that's only good enough for a specific set of libraries, and either
you have to repackage a collection of different library combinations
or you have to support installation in some manner. appengine-homedir
is one attempt to get installation working reasonably. The intent of
appengine-homedir is also that you check app/ into version control
(but not the enclosing virtualenv environment). It would be kind of
nice if app/ had some script included to recreate the enclosing
virtualenv environment.
Another detail I guess is what your app is named -- each person might
name it differently, and that effects the file locations, so makes a
simple tar/zip file harder. Are app names worth it? I don't know...
could you name them all "app" and be done with it? If you start
combining multiple apps it might matter, but people haven't done that
much (though it is possible, and several GAE tools are distributed
that way). Also I mostly got rid of configuration, as GAE apps aren't
generally "configured" (due to the static nature of the deployment).
But that broke paster controller and paster shell (though with what
sitecustomize does paster shell isn't as necessary). Restoring
development.ini, or allowing it as an option, would be easy enough to
do.
--
Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
