Peter's Blog

Redefining the Impossible

Turbogears deployment


So I develop an online questionnaire (and learnt to spell that word) for the online intranet in turbogears, it takes maybe a day total to have a nice sqlite database driven app that walks you through the questions, allows you to go back and forth, handles errors, themed exactly like the main intranet (drupal) really nice.

After developing under windows I casually copy the files to the ubuntu intranet server and try installing it in a virtual path under the root domain (e.g. intranet.com/subdirectory). Then I mess around for hours because the mod_python support for cherrypy appears to be hacked on, the support for mapping applications to virtual paths in turbogears using servo.webpath is broken and cherrypy support for virtual paths boils down to this hack which it states is buggy but doesn't say what the bugs are! The main bug I see is that IT DOESN'T MAKE ANY DIFFERENCE.

Argh.

I can get the app to work but only the index, none of the other methods in the controller are recognised.

While googling for this I came across an interesting django vs turbogears review here. He makes an interesting point: django sites survive slashdotting. I look at the cherrypy site and see where cherrypy is being used: um, sorry but these sites don't look all that impressive compared to the django equivalents.

So I'm disillusioned with cherrypy: while the raw api is clean, it looks a bit hacky and the documentation is poor ('in progress') by comparison to the other elements of the turbogears stack. I have no idea whether django supports virtual paths but it Just Worked under mod_python. Should I switch back to that, given that they are working on cleaning up their database api? I'd be tempted to stick with kid even if I went back to django, like this guy.

Dunno what to do, almost tempted to learn ruby, I'm that fed up with it all.

UPDATE: It took me a few days to figure the problem out: I had an extra .htaccess file I didn't know was there, causing mischief and interfering with whatever I did in the main config file. I've got rid of it and turbogears/ cherrypy is working fine.

The turbogears server.webpath="/subdir" does not seem to be working (as mentioned in the turbogears issue tracker) but if I hack my controllers.py file I can work around it:

class subdir:
    @@turbogears.expose(html="tgpcw.templates.welcome")
    def index(self):
        import time
        return dict(now=time.ctime())

class Root(controllers.Root):
    subdir = subdir()

I enabled this in the apache2 config file thusly:

<Location "/hands">
    SetHandler mod_python
    PythonHandler mpcp
    PythonDebug On
    PythonPath "['/var/www/tgpcw'] + sys.path"
    PythonOption cherrysetup tgpcw_start::mp_setup

    AllowOverride All
    Order deny,allow
    Deny from all
    Allow from all
</Location>

where tgpcw is the name of my turbogears stuff.


Filed under: django python turbogears

5 Comments

michele Says:

over 3 years ago

Maybe you have already done it, anyway take a look here for TG+mod_python:

http://trac.turbogears.org/turbogears/wiki/ModPythonIntegration

Hope it can solve your problems, if you need more help please consider subscribing to to the google group and even filing a ticket on the TG trac.

Adrian Holovaty Says:

over 3 years ago

Yeah, you should definitely come back to Django. CherryPy is quite odd -- it makes some strange design decisions, IMHO. It's (one of) the major design smells of TurboGears.

You're right about Django having a proven track record. I'm using it right now at washingtonpost.com: See projects.washingtonpost.com/congress .

Peter Says:

over 3 years ago

I'm waiting to see how the magic removal goes. I think django's url mapping is a much better system than mapping url elements to objects and methods:

  • More control
  • Easier to see what is going on
  • No need for 'expose' for access control

But I do like kid as the syntax is simpler ($(python), py:). It doesn't really bother me that it's speciality is xml and it is questionable for plain text templates.

One final thing about TurboGears is that there seem to be big plans for the next version and I detect the faintest hint of vapourware: I get the impression that they have got all enthusiastic about the potential and reality might just set in. This is just an impression.

Peter

Kevin Dangoor Says:

over 3 years ago

Regarding your original trouble: TurboGears in svn no longer requires the VirtualPathFilter (setting server.webpath automatically has the same function).

Different people do have different opinions about how URL mapping should work. I think CherryPy's is very easy and flexible. I have considered integrating Routes for the ability to be backwards compatible with existing URLs easily, but I haven't felt constrained by CherryPy's URL mapping. This is one of those places where people will always vary in opinion. (Just like the number of people who prefer Cheetah to Kid... you and I think Kid is nice to use, others disagree.)

"One final thing about TurboGears is that there seem to be big plans for the next version and I detect the faintest hint of vapourware: I get the impression that they have got all enthusiastic about the potential and reality might just set in. This is just an impression."

0.9 has moved slower than I had hoped, in part due to things I've had going on. In the meantime, some folks have contributed some very nifty new things that ultimately make it a better release. At this point, there's nothing major underway for the release and we're just busy closing tickets to get the new release out. New features (not vaporous, they're in svn now): internationalization, the "Toolbox" which provides a browser-based GUI for working with your database, i18n, and more, authentication/authorization, a new forms/widgets handling package and a number of other features.

Peter Says:

over 3 years ago

I am honestly pleased to hear that TurboGears is progressing well. As I tried to convey, the vapourware thing was only an impression I had and I don't even know where I got it.

Since I fixed my cherrypy problem and since it was my fault and I have done more coding in it I will stick with TurboGears for now.

Incidently Kevin, thanks for creating the TurboGears project and giving me some choice.

Peter

Have Your Say

I welcome constructive comments or questions but I reserve the right to delete any comments that displease me.

Who are you?

(Optional) If you enter an email address here I might email you back. Your email address will not be sold to spammers or shown anywhere

What do you have to say?