Trying to understand Python web-development

[Paul Boddie]

On 30 Jan, 21:27, walterbyrd <walterb... at iname.com> wrote:
> Thanks for all that posts. This thread has been helpful.
>
> I have seen a lot of posts about the importance of decoupling the
> deployment technologies from the framework technologies. This is how I
> have done that in PHP. I develop on my home box. When I get something
> working the way I want, I ftp those files to the remote server. To me,
> that seems to make more sense that trying to run two different web
> servers on the same system. My PHP system involves no monkeying with
> special config files, or running special servers to couple the
> different environments, or setting special ports, or paths. For PHP
> development, I don't even need ssh access.

Various solutions like WebStack or WSGI should permit you to choose
Apache and/or other servers and hopefully not notice big differences
in your application. Various WebStack examples should run out of the
distribution, admittedly using their own server processes, and there's
plenty of choice when it comes to configuration complexity across the
supported server technologies (CGI, mod_python, Java Servlet, and so
on). Perhaps the range of WSGI adapters offer a similar range of
choices. In short, flexibility is definitely here for Python Web
frameworks.

I'd agree that PHP is usually configured to be as easy to deploy as
possible, but I guess that's because the (admittedly straightforward)
configuration is typically already done for users of shared hosting.
I've just got into a shared hosting situation, and PHP is set up
alongside CGI and static pages - you just drop the files into the
directory and Apache serves them up according to their filename
extensions. To configure mod_python isn't that much harder, but there
are some tricky elements which often defeat people. However, some
hosting providers (such as mine) do make it just as easy, but just not
at less than $1 per month.

> > I think that this (the ease of PHP application deployment) is one of
> > the things that keeps Python framework developers up at night
>
> I think you may have something there. For $10 a year I can get an
> account at dollar-hosting.net, copy some php files there, and that's
> all there to it. I have been beating my brains out trying to get
> anything working with a python framework, and I have not been able to
> do it. I even bought VPS hosting just for the sake of python
> development.

I have to admit that I've only fairly recently had experiences with
getting Django and MoinMoin working from scratch, and the latter is
mostly set up on Ubuntu systems if you install the package and know
how to add a site to the Apache configuration. My observation with
regard to Django 0.96 (at least, and perhaps 1.0 is a bit better) is
that there's a lot of stuff that I'm moderately comfortable with -
setting up mod_python, for example - but I'd be really put off doing
any of it if I hadn't had the experience of doing it (and
troubleshooting it) before.

MoinMoin seems to be easier: you just have to copy the files into the
right places. It's a lot nicer than some other solutions, notably "old
school" Perl applications, which need lots of Apache tweaking to avoid
easily overlooked insecurity issues. Nevertheless, there's potential
for making mistakes, having the wrong permissions, and so on.

> But, I still can not seem to make the quantum leap of
> getting something that works locally, to work remotely. BTW: with the
> VPS hosting, I had to install and configure my own web-hosting and
> PHP, including setting up lighttpd with fastcgi and php modules - and
> I still found that much easier than getting anything to work with
> python.

System packages of Python frameworks should mostly leave you with only
a bit of configuration file editing to do, perhaps with some database
initialisation where necessary, but I suppose that some frameworks
don't have up-to-date-enough packages. Even then, perhaps it's the
last bit which causes the most problems - you'll have to remind us
where you got stuck, I think.

Paul