Pylons on Westhost

How to get Pylons working on Westhost 3.0 (WH).
This assumes you have SSH (like telnet) access to your Westhost account, but you can do most of this using FTP or the westhost control panel file manager, if you prefer.

We had previously tried and failed to install pylons (prior to Westhost 3.0), so decided to use Virtual Python instead, where you can change whatever you like. It makes ~/bin ~/include ~/lib to replace the system versions, and when you run python, it runs ~/bin/python and uses your lib etc.
Just grab virtual-python.py and run it. (It’s possible you don’t need Virtual Python under WH 3.0, don’t know.)

Now you can get ez_setup.py and do python ez_setup.py which gives you easy_install, which you’ll use for installing most other things. Then do easy_install -U setuptools, easy_install pylons, easy_install sqlalchemy. These all went into ~/wherever (not the system directories.)

Now you can cd ~/www and paster create -t pylons prj
which creates a project called prj (our version of helloworld). cd prj and edit development.ini to put in your domain name (yourdomain.com) instead of 0.0.0.0 and change the port from 5000 to 81. You can serve your new site with: paster serve –reload development.ini
(~/www/prj/prj/public/index.html is the default page).

With your web browser, go to http://yoursite.com:81/ and you should see your new site.

How do we get this served from the usual Apache 2.0 (so we don’t have to run paster) ?

Pylons can run using mod_python, which is a way for Apache to include the Python interpreter.
Westhost 3.0 already supports mod_python. You can verify this by adding these lines to /etc/httpd/conf/httpd.conf: <Location /mpinfo>
SetHandler mod_python
PythonHandler mod_python.testhandler
</Location>
You can apachectl restart to restart your web server (or Restart Account from WH Site Manager).
And then with your web browser, going to http://yoursite.com/mpinfo

See pylonshq.com, Production deployment using mod_python and put wsgi.py into your ~/lib/python2.5/site-packages/mod_python/ folder (I actually put it into /usr/local/python/lib/python2.5/site-packages/mod_python).

cp development.ini production.ini #copy file
edit production.ini #using vi, pico, whatever you know
remove comment character from line: #set debug=false (so now it will set debug=false)
create startup.py containing these two lines:

from paste.deploy import loadapp
app = loadapp("config:/var/www/html/prj/production.ini")

create .htaccess containing:

SetHandler mod_python
PythonHandler mod_python.wsgi
PythonPath "['/var/www/html/prj', stuff explained below] + sys.path"
PythonOption wsgi.application startup::app
PythonOption SCRIPT_NAME /prj


The _stuff explained below_ is the path info that your new python has:
python #run your virtual python
import sys
print sys.path
copy all the path places you see into _stuff_ above, except the first empty one ‘ ‘.

Now you can go to your web browser:
http://www.yourdomain.com/prj/ #and you should see the default page ~/www/prj/prj/public/index.html, this time served by Apache.

It answers on port 80, regardless of the domain/port in your production.ini, which is only used by paster.

JSON Dates and Dojo Grid identifier=primary key for multiple columns

Problem: JSON doesn’t specify a date format.  Dojo wants json dates in the form {_type:’Date’,_value:’2007-12-31T12:34:56.789′}.  Using jsonlib.write’s on_unknown handler, we can test for the datetime type and format it in this way.  On the way back, when items are changed in the browser, we did Date.prototype.json = function() {return dateFormat(this)}, so that dojo.toJson would know how to format dates.  This means that “json” is using two different formats for the two directions (an object on the way to browser and a string on the way back to server.)  The string format for the date itself is the same in the two directions (which took some work since dojo appends the time zone offset but Python’s datetime’s .isoformat function does not, and there are some milliseconds/microseconds issues.)

Next problem: Dojo grid (ItemFileReadStore, actually) likes to have an ‘identifier’ column, which is used to quickly find a row (‘item’).  We have some tables that have multi-column primary keys (PKs).  I had first just been lazy and used the 1st column of the PK, but Dojo was smart enough to see that wasn’t unique when I used real data.  I looked at perhaps a hundred dojo grid data examples, and EVERY ONE had a single-column primary key.  However, you can use an OBJECT for identifier, and if it has a .toString() method then you might be able to have it combine the primary key columns on-the-fly {x:10,y:20,toString:function(){return this.x+’|'+this.y}}.  I’m thinking this will be messy because 1) jsonlib won’t know how to emit a javascript function; 2) didn’t figure out how the object’s toString function references the item’s data columns (does this.pk0 work?); 3) what if we change a PK’s value?  “ItemFileWriteStore does not have support for changing the value of an item’s identifier“.

The plan at the moment is one of: 1) construct our own new one-column primary key that is a concatenation of the actual primary key columns, such as NJ|Trenton.  This won’t be shown on the grid, and for now, there is no editing of PK values anyway.  2) just use a sequence number and fix when we finally have some use for the identifier; 3) switch to the ‘table’ format where we don’t need an identifier.