Deploying a TG app

[Aggelos Orfanakos]

I've completed writing my first app with TurboGears and I want to
deploy (?) it -- that is, transfer it in another machine and make it
work there. Is there an elegant solution for this, or am I supposed to
install TG in the target machine too?

Thanks!

[Aggelos Orfanakos]

(I meant install TG in the target machine and transfer my app directory
there.)

[SuperJared]

Aggelos,

While I have not deployed a TG app myself, there are a few ways to go
about it. It seems, so far, that you have 2 options in deployment:
Mod_python or Lighttpd.

Take a look here:
http://trac.turbogears.org/turbogears/wiki/DocumentationPlayground

[Bob Ippolito]

or mod_proxy, or anything WSGI, or just using the built-in server...

-bob

[Aggelos Orfanakos]

What I meant was, is there an easy way to _move_ my app between
systems. Like, move a single file and then install it on the target
system? For example, many packages only require that you do: $ python
setup.py install

And what about the TG components? How can I make a machine in which TG
isn't installed, run an app written in TG? Is it necessary to install
TG in the target machine too?

Thanks. :-)

[Kevin Dangoor]

Yes, it is necessary to install TurboGears on your deployment machine.

If you quickstarted your application, you should have a setup.py file.
"python setup.py bdist_egg" will give you an Egg file that you can
copy over to your deployment machine and easy_install.

When you do that, your start script is available to start up the
TurboGears server.

Kevin

[Aggelos Orfanakos]

It worked like a charm. Thanks for your help.

[Phillip J. Eby]

Aggelos Orfanakos wrote:
> It worked like a charm. Thanks for your help.

Note also that as long as the setup.py lists TurboGears as a
requirement, it should be possible for somebody to install your
application with just the .egg and easy_install - including the
installation of TurboGears itself, with all its dependencies.

This is a pretty killer feature for application deployment, especially
since it will also upgrade TurboGears if you use an app that needs a
later version of something, etc. If your application has other
dependencies besides TurboGears, those can get installed too.

[Aggelos Orfanakos]

I've managed to get to my app through Apache and mod_proxy (in fact,
using mod_rewrite with a rule flagged as [P]). The only problem now
seems handling static files. For example, CSS and images files included
and showing up in my development environment, do not show up in the
target machine (production environment). Any ideas?

[Lee McFadden]

Does your prod.cfg have the same entries for static dir's as your
dev.cfg? Apologies if you've already checked this, but it's almost
always the simple things that get overlooked. :)

[bon...@gmail.com]

my quick and dirty way:

use the none-root installation for Turbogears

Then just tarball the whole directory of it and send to the target
machine. So long the base system is relatively compatible(x86 won't
work on PPC), this is the easiest. It also has the advantage of self
contained and don't need to worry about what version of certain
component the target use. This is especially handy for packages that
needs stability. I can have different versions of my app running at the
same time(upgrades, UAT, mirgration) without messing with the source
code of "require package-version". Of course, this is not for some
arbitary download and install type scenario which the setuptools is
designed for.

Of course, if your app requires setuid type privledges, it may not
work.

[Aggelos Orfanakos]

(No need for apologies, since you are trying to help.) I have already
checked that. Sadly, they are identical. :/

[Aggelos Orfanakos]

I did it! I didn't use mod_rewrite (I've never managed to learn how to
use this module), just mod_proxy. It can also serve static content. My
mistake was using "/static/css/blah.css" in my templates, instead of
"static/css/blah.css" (notice the initial '/' missing). Although I
don't know *why* it didn't work with an absolute path. When using
dev.cfg, it worked like a charm. :/

[Aggelos Orfanakos]

That works for me too. In fact, this is what I do (with the difference
that I don't make a tarball and use scp -- I have an SVN repository on
the host machine and execute svn checkout on the target machine).

Anyway, after *a lot* of effort, I got the whole thing running. I don't
know if it's me, but it looks *really* awkard in deployment. I mean,
you have to setup a proxy server and then find a way to daemonize your
app's -start.py just to have your app running? (I never managed to do
this.) IMHO, there should be an easier method of deployment -- although
I don't know if it is technically feasible. This is what most
frameworks lack.

[bon...@gmail.com]

I don't know what system you are using but debian(which I run) has some
standard deamon helper things which should make daemonizing arbitary
program relatively easy.

Beside, I don't mind the manual procedures of setting apache proxy and
the like as I would like to know what I am doing rather than some
really automatic things which unless is really well written(which is
difficult and I seldom find one that is, especially on *nix except for
the core system packaging), would fall apart and I need to debug
someone else' smart script which is not smart enough.

[Aggelos Orfanakos]

You are mostly right. It might be due to my incomplete knowledge of
Unix (I am using Gentoo). I don't consider myself a newbie, but I am in
no way near 'guru' or the like. Anyway, your idea about the existence
of a "daemonizer" helped me remember that I have read about it
somewhere before. I'll look into that.

As for the manual procedures, I was mostly comparing the Python
frameworks with PHP. God, I *hate* PHP's ugliness and I adore Python's
cleaness, but the one good thing that PHP *has* is instant deployment
-- it beats everything else, hands-down. Deployment is, and always was,
the cause of me having difficulties with the various frameworks (and
the reason I still program in PHP).

[Aggelos Orfanakos]

One more thing. I have my app installed in the target machine (.egg)
using prod.cfg. TG assumes that the path to the database (file) exists
(e.g. you have taken care of creating it using tg-admin) or it rather
creates it if it doesn't exist? I had some problems when not creating
the database a priori. I also checked and saw that if I run my app with
prod.cfg without any database file, later, it only contains 1 table of
CatWalk and not any tables of my model.py. So my best guess is that you
_have_ to create it yourself. Am I right?

[Kevin Dangoor]

You're correct that you do have to create the database.

Odds are good that your development database and production database
are two different things (one would hope), and it's even possible that
you might use sqlite in development and something else in production.
(SQLite, having database-level locks, is a great database for working
single user... not so great in a webapp being used by multiple
people.) So, both databases need to be created with tg-admin sql
create.

Kevin

[jorge....@gmail.com]

about the CatWalk part. it's a little *feature* it was, i have notice
that table also it's call catwalkstate or something. and it's use to
hold the default cols values. as in show id, or column name,etc.

Anyway what i wanted to say is that, that table is not part of your
model, so things like sqlobject-admin create,sql,drop wont alter it.

I had a little trouble with it since i had a typo on one class, i put a
"test" field instead of "text" the 1st time i was trying to use
catWalk, and it got stuck on there, throwing errors until i find that
table and fix it.

As for creating the database, i think 20minwiki should say that
explicitly somewhere, don't need to say how, just that you must create
the db first.

[Kevin Dangoor]

The 20 minute wiki does... it explicitly does a tg-admin sql create.

The question from this thread was about moving an application to a
production server, where you need to re-run tg-admin sql create to get
your production database setup.

Kevin