This version of the page http://maxischenko.in.ua/ (0.0.0.0) stored by archive.org.ua. It represents a snapshot of the page as of 2006-02-03. The original page over time could change.
In the middle of nowhere

HOWTO: Installing TurboGears app on shared hosting

January 23rd, 2006

Here is a recipe I used to install TurboGears pre-0.9 release (yes, the trunk) on a hosted environment (python-hosting.com). The information is taken partly from this TxD thread, DocumentationPlayground and Turbogears Google group archives.

The HOWTO describes how to install TurboGears app on a shared hosting account, whereas Apache forwards HTTP requests to the CherryPy server and installation files is sandboxed to user’s homedir (vs. usual system-wide setup).

1. Prepare non-root python environment

This is easy with Ian Bicking’s script:

$ wget http://svn.colorstudy.com/home/ianb/non_root_python.py
$ python2.4 non_root_python.py

This copies system Python2.4 files to your ~/bin, ~/lib/python2.4 and ~/include directories. The “non-root” python executable will reside in ~/bin.

2. Install TurboGears itself

$ svn co http://www.turbogears.org/svn/turbogears/trunk turbogears
$ cd turbogears
$ cd thirdparty/cherrypy/
$ ~/bin/easy_install -D -s ~/bin/ .
$ cd -
$ cd thirdparty/kid/
$ ~/bin/easy_install -D -s ~/bin/ .
$ cd -
$ ~/bin/easy_install -D -s ~/bin/ .

Note that I also had to installKid and Cheetah from SVN; this is currently required for TG to operate properly. To verify the install try to run ~/bin/tg-admin command.

3. Install Turbogears application

Next step is to install your application. If you’re using an egg (and I think there is no valid reason you shouldn’t) it’s simply a matter of running ~/bin/easy_install -s ~/bin TheApp-1.0.egg. Btw, to build an egg just run setup.py bdist_egg from within your development copy.

4. Configure the application

This is a matter of writing proper prodcfg.py. The settings to pay attention to are: sqlobject.dburi, server.socket_port and server.log_file. In a shared hosting setup, the socket_port and log directory to use are given by the hoster so just make sure you’ve specified them correctly.

When running proxied behind Apache you will also need to add the following to the setup:

path(\"/\")
base_url_filter.on = True
base_url_filter.useXForwardedHost = True

This ensures CherryPy will use “X-Forwarded-Host” header set by Apache to figure out publicly-visible address of the application.

5. Running the application

One final tidbit is how the application is started and run. On python-hosting.com they use a special “launching” .cgi that need to be updated to use your start-app.py script (which is put into ~/bin by setuptools).

That’s it. It worked for me but if you run into a problem don’t hesitate to ask.


TurboGears

January 19th, 2006

I spend so much time with TurboGears recently that I decided to setup a separate category for it in this blog.

TurboGears is the first major open source project I feel like actively contributing to. It’s still in the early stage of development which is no good for users but great for developers — feeling the power to “make a difference” and be able to push the shape of the project is great.

Kevin even granted me commit priveledges but so far my biggest contribution was i18n command-line tool (besides a slew of bug reports).

Besides fun, working on a major distributed project is a valuable experience for developer. For me it’s also a chance to get credibility and exposure as a high-skilled Python developer.

Exciting stuff.


indie game developer lessons

January 18th, 2006

Thomas Warfield on other’s game postmortem:

There is no way I would do a deal today to sell my games in a portal without getting the names, addresses, and email addresses of the customer. Absolutely no way. It does not matter how many copies they think they can sell, or what percentage they give. It is not worth it, it is not a business.

I’m not in that business but it’s still an interesting read: Why Pyrogon failed.


the most important thing

January 2nd, 2006

From here:

The absolute number one most important thing when starting a new business is figuring out HOW you will get the word about your product out there. You should be thinking about this the whole time.
This is so true, at least in my experience. My past venture (postman.com.ua) failed exactly because I was busy working on the product and leave marketing for later. Now I have another idea but I’m not going to dive into it until I figure out how to reach potential customers.


RAD web tools in Python: Django vs. TurboGears

December 28th, 2005

As time and market pressures continue to increase we as a developers forced to build more advanced software in less time. Of course, advances in tools suppose to make this possible.

Recently, faced with another to-be-shipped-yesterday application I had to evaluate current Python web frameworks to choose one that allow a quick yet solid implementation. Here is some notes on the process.

The candidate list was quickly reduced to two choices: TurboGears and Django. Both are on the rise, popular and advance quickly. What’s most important, these frameworks stress on fast development and that’s what I was loooking for.

TurboGears

Relies on existing and more-or-less widely used Python components for most of heavy-lifting and provides consistent and unified stack for web development. Uses SQLObject as ORM tool, Kid for templating, CherryPy to handle web requests.

A lot of work went into simplifying web development, like validating and parsing HTML forms, AJAX integration,  automatic CRUD interfaces, i18n, etc. Unfortunately, most of this is still in the work, to be released in the next anticipated release (0.9). Documention is still quite scarce but check out Kevin’s devcasts where he describes some of the upcoming features.

Consequently the code is not stablized and documentation are scarce. I think TurboGears is the most promising option on Python web development area but I honestly can’t recommend it on short-term project with a tight schedule.

Django

Despite its relative novelity the framework has been in use for a couple of years so you can expect certain amount of polish and ‘completeness’. For instance, documentation is very good, there is both tutorial and reference-style material.

Django has sophisticated means to do data modeling (a.k.a. ORM tool) which are coupled with default administrative interface. This allows to build simple CRUD web-applications really easy. There is built-in authentication and permission system, tool to handle form building/parsing/validation, i18n support and more. If it fits to your project you could get a real gain by reusing all this great functionality. If you need more or in a different way, well, you’d still leverage framework but gains will be relatively minor.

It looks relatively mature but I have run into a couple of bugs with the latest release (0.9).

My biggest complain with it is that most of the functionality it provides is written from scratch versus using some established tool. Which means you’d have to learn yet another ORM tool, yet another templating system and yet another request/response object; and your knowledge will remain limited to Django’s domain. It’d probably be understood a couple of years ago but today this make Django to feel ‘legacy’ (IMO).

Summary

For a short-term project with CRUD interfaces or minimal amount of custom logic I’d go with Django. It has slick and customizable (within limits, but nevertheless) admin interface which could eliminate most of work on UI (e.g. intranet informational portal).  For a long-term project or one with diverse requirments I’d prefer TurboGears, I think it has more potential and that will prove itself over longer timespan.

See also: Python Web Framework Niches.