Pylons on Google App Engine article - pylons-discuss

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Pylons on Google App Engine article
Received-SPF: pass (google.com: domain of ianbick...@gmail.com designates 209.85.220.216 as permitted sender) client-ip=209.85.220.216;
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:from:date
         :x-google-sender-auth:message-id:subject:to:content-type
         :content-transfer-encoding;
        b=j7d8M4A+K7iUbTAt/bkQ/MYITQr2sxy04rN24hUQe27HtglC2FSmZda7wQIJIZas+A
         ubOe+fmGr6YR/ORDhDuYw2GbMyk6C6M6uXJfB8rsLhknPNJMDpRGn2xCQSx7z/IjjZeb
         xMmd2MBKGUvegka5OShOEuMr1irI0ag451JI8=
MIME-Version: 1.0
Sender: ianbick...@gmail.com
In-Reply-To: <6fb6dbfe0910161557i473057b1n33244315187c6...@mail.gmail.com>
References: <65057e3a-e595-48fa-93c5-5c2b316f4...@j24g2000yqa.googlegroups.com> 
	<6fb6dbfe0910141435g57adcb0dxf91d3c60ef36f...@mail.gmail.com> 
	<b654cd2e0910142210h7f00a23ub7210d62cf4f5...@mail.gmail.com> 
	<6fb6dbfe0910150959u5d1ce459nb4a78e2533e4...@mail.gmail.com> 
	<0d6f2231-3913-4d64-87af-b6646c0ea...@t2g2000yqn.googlegroups.com> 
	<6fb6dbfe0910151201t7c9d992frc3757fbd575ed...@mail.gmail.com> 
	<b654cd2e0910161104n186ca533kea97d8533b3d...@mail.gmail.com> 
	<6fb6dbfe0910161557i473057b1n33244315187c6...@mail.gmail.com>
From: Ian Bicking <i...@colorstudy.com>
Date: Sat, 17 Oct 2009 11:40:09 -0500
Message-ID: <b654cd2e0910170940o2e516bf6g559c00a9b1acf...@mail.gmail.com>
Subject: Re: Pylons on Google App Engine article
To: pylons-discuss@googlegroups.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 16, 2009 at 5:57 PM, Matt Feifarek <matt.feifa...@gmail.com> wr=
ote:
>> I don't use paster serve, and wouldn't recommend it. =C2=A0You can/shoul=
d
>> 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=
?

On GAE specifically, dev_appserver does all the fixups and security
restrictions to make it a mostly representative environment.  So you
should just use dev_appserver.

>> 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.

pip install works with appengine-homedir.  A couple things are
installed outside of the app/ directory, but once it's setup there's a
file in lib/python2.5/distutils/distutils.cfg that makes everything
install into app/lib/python.

When I update a library or install something new, I just run another
commit after.

>> =C2=A0appengine-homedir
>> is one attempt to get installation working reasonably. =C2=A0The intent =
of
>> appengine-homedir is also that you check app/ into version control
>> (but not the enclosing virtualenv environment). =C2=A0It would be kind o=
f
>> 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 yo=
u
> don't recommend using paster serve.

I recommend the venv for running python interactively, running tests,
and installing things.

>> that way). =C2=A0Also I mostly got rid of configuration, as GAE apps are=
n'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). =C2=A0Restoring
>> 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.

It also sets up the data store, so you can access and use your models.
 It doesn't set up the entire configuration of your app, but the most
important configuration is generally persistence, which sitecustomize
handles.  And maybe it could even handle more if it was useful to do
so.

--=20
Ian Bicking  |  http://blog.ianbicking.org  |  http://topplabs.org/civichac=
ker
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
