Month: December 2009

Last month, Dreamhost announced their new support for Django using Passenger WSGI. (Instructions are posted here.)

The process is pretty simple. First, I setup a new subdomain for the app. One can probably setup a Django app using a subfolder of an existing domain, but I haven’t explored that yet. As instructed, I setup the subdomain with the Passenger option.

Next, I added a database for the domain. Nothing tricky or new here.

The final step in their instructions was to download and run the setup script. I was a little confused about where I should run it, as the instructions referred to the “directory for the application”. After a little experimentation, I figured out that I should be in the root directory for the subdomain (created when the subdomain was created), which has the /public directory in it. The script asks a few questions and runs quickly. At the end, I had a settings.py and urls.py, the database was initialized, and the admin app was ready to go. If the programmer is starting a new application, this is a good place to start.

However, I have already been working on my app on my laptop, and I wanted to copy it to the server. Since I’m using Subversion to store my code, it was easy to use the svn co command to copy the files over – after I first moved the recently created settings.py to a safe location.

I copied the database and media location entries from the new settings.py into the existing version with my application. I typed in the URL and was ready to go.

EXCEPT … I forgot about a problem I hit when installing another Django app on Dreamhost using the older FastCGI configuration. It seems that I have to qualify a couple of the file names in settings.py and urls.py to help Django find them. Specifically, the applications listed in INSTALLED_APPLICATIONS need to have the project name appended to the beginning. The same for imported URL files. Those two changes did the trick.

UPDATE: To solve this path problem, I added this line to passenger_wsgi.py:

sys.path.append(os.path.join(os.getcwd(),'project')) - where 'project' is the project name

EXCEPT … my application uses Python constructs (in this case, decorators) that were added after version 2.3, which is the default on my Dreamhost server. With my earlier Django install, I had installed Python 2.5 in my /bin folder and was able to directly the server to use that version. Even after following the instructions I found in a discussion attached to the wiki page, I was not able to get this to work. The command I added to pasenger_wsgi.py was:

if sys.version < "2.5": os.execl("/home/gentryadmin/bin/python", *sys.argv)

Instead of using the new version, I see a screen telling me I have hit an Internal Server Error. I've yet to find a log file that has information on this error.

I can change the decorator code to Python 2.3 friendly syntax, but this problem will get in the way when/if I want to use other Python/Django applications or modules. Hopefully, I can get this fixed.

Any ideas or thoughts? Please leave a comment below.

Today I setup Eclipse SQL Explorer in my Eclipse environment. I’ve been looking for a good SQL plugin for a while, and I stumbled on this while searching for something else.

Installing it was easy, as there was an Eclipse update mechanism link provided.

Next, a little tougher. My first DB to try is in SQLite format, so I had to find a SQLite Java driver. Google saves me once again, pointing out sqlitejbdc from Zentus. I put the .jar file in the eclipse/plugins folder.

The SQL Explorer driver entry needs to be linked to the java driver in order to access the DB. The SQL Explorer site offered an example for MySQL, but the advice works for any DB driver. Basically, the .jar file is added in the Extra Class Path tab, and the driver can then be selected. sqlitejdbc only contains one driver, so it was automatically loaded.

Creating the connection was easy. Just select the SQLite driver that was just modified above, and then enter the path to the db file. I was in the db and SELECTing data in no time.

(See the earlier post)

A little more research after a suggestion from the server admin has confirmed that I can’t see Apache environment variables with os.environ in a WSGI interface. Instead, those are available through the request object. Since I don’t yet have a request object when starting up the app, I had to find a new way to ID the instance.

My server admin suggested that he add a system environment variable that would hold the instance name. I can read those variables just fine. He did, I read it, and all is well. New code:

import os
TIER = os.environ.get('TIER','') ## get the value of the TIER env variable

if fqdn == 'dashdrum_laptop':          ## laptop
    SERVER_ENVIRONMENT = 'Laptop'
elif TIER == 'dev':                ## dev server
    SERVER_ENVIRONMENT = 'DEV'
elif TIER == 'qa':                 ## qa server
    SERVER_ENVIRONMENT = 'QA'
elif TIER == 'prod':               ## production server
    SERVER_ENVIRONMENT = 'PROD'

Note that I’m still using the fqdn to ID the laptop.