On Fri, Oct 16, 2009 at 1:04 PM, Ian Bicking <i...@colorstudy.com> wrote:
>
> 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.
>
Yes, it seems to be necessary in all of my experiments to create that file
to make paste/ into a true package. No big deal.
> 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.
>
Would you mind expanding on that a little bit? Why don't you recommend it?
> > 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.
>
Interesting. I'll have to try that.
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.
Cool. Good concept. But it seems like once you do something like that (or
like moving your libraries into the GAE "app") you can't manage the
virtualenv install anymore (like adding new distributions with pip). I
suppose one can always manually add them.
> 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.
Still, a "stock" pylons app could be hosted on BitBucket; just clone and
run. Cool idea.
> 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.
>
It *seemed* to me that once appengine-homedir got running, the VE is
basically moot; you no longer run the devappserver from it, right? Since
your runner.py script does all of the sys.path manipulations, there's no
point in keeping the VE bin and lib and what-not around, especially if you
don't recommend using paster serve.
> 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...
>
Since each GAE is insulated in its own namespace, if the whole world named
their apps "app" it wouldn't matter, IMO.
> 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
>
Why isn't paster shell necessary? Seems like sitecustomize.py is mostly
about fixing imports and shim'ing things into sys.path.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
