Trying to understand Python web-development

[walterbyrd]

I don't know much php either, but running a php app seems straight
forward enough.

Python seems to always use some sort of development environment vs
production environment scheme. For development, you are supposed to
run a local browser and load 127.0.0.1:5000 - or something like that.
Then to run the same thing in a development environment, I have to
configure some files, or touch all the files, restart the web-server,
or something. Why is that?

Python also seems to require some sort of "long running processes" I
guess that the python interpretor has to running all of time.

I am not really sure about what wsgi is supposed to accomplish.

 

[Joe Riopel]

I am not really sure about what wsgi is supposed to accomplish.

This will explain WSGI: http://www.python.org/dev/peps/pep-0333/

 

[Bruno Desthuilliers]

walterbyrd a écrit :

I don't know much php either, but running a php app seems straight
forward enough.

Mmm... As long as the whole system is already installed and connfigured,
*and* matches your app's expectations, kind of, yes.

Python seems to always use some sort of development environment vs
production environment scheme.

s/Python/some frameworks/

For development, you are supposed to
run a local browser and load 127.0.0.1:5000 - or something like that.
Then to run the same thing in a development environment,

I suppose you meant "in a production environment" ?

I have to
configure some files, or touch all the files, restart the web-server,
or something. Why is that?

Developping directly on a production server is defiinitively a no-no,
whatever the language. So you *always* develop un a development
environment. In PHP, this imply having a running HTTP server - usually
Apache - correctly configured. Some Python frameworks, OTHO, ship with
their own lightweight Python-based http server, which usually makes
things far easier. Since quite a lot of web programmers already have
Apache running on port 80, the framework's own server usually runs (by
default) on another port. Also, most of the time, on the production
server, you choose some other more appropriate deployement solution -
which may or not include Apache - depending on the context. So the nice
point here is that:
1/ you have way more freedom wrt/ possible deployment solutions
2/ you don't have to replicate the whole damn thing (if ever possible)
on your local machine to develop the app.

Of course, the actions to be taken when updating your app on the
production server greatly depends on the deployment solution.

Python also seems to require some sort of "long running processes" I
guess that the python interpretor has to running all of time.

s/Python/some frameworks/

You can write web apps in Python using plain cgi, you know. It's just
very inefficient due to how cgi works - to make a long story short: the
system has to launch a new process for each request calling your script,
and you have to rebuild the whole damn world each time your script is
called. Note that PHP suffers at least from the second problem, which
can make it somewhat inefficient for some kind of applications.

The point of long running processes is that most of the world is only
built at startup and stays here between requests.

I am not really sure about what wsgi is supposed to accomplish.

First and mainly, allow Python-based web apps to be independant from the
deployment solution, by adding an indirection level. Instead of having

[yourapp]<-->[http_server]

which only work for the http server you targeted, you have

[yourapp]<-->[wsgi]<-->[http_server.wsgi_adapter]<-->[http_server]

which works for any http server for which a specific wsg adapter exists.

There are also some other benefits since, the way wsgi works, the [wsgi]
part of the above schema can include quite a lot of other things,
sometimes without your application being aware of it (you may want to
look for 'wsgi middleware' for more on this).


HTH

 

[Joshua Kugler]

Python also seems to require some sort of "long running processes" I
guess that the python interpretor has to running all of time.

What you probably don't realize, is that in 99.9% of the situations you've
come across, PHP is already a process running all the time. It's called
mod_php, and it's a PHP interpreter running inside of apache, thus a "long
running process." It's just not as obvious. You can do the same thing
with Python via the mod_python module, thus putting the python interpreter
(instead of the PHP interpreter) inside the Apache process. Other web
servers have similar setups. Google for FastCGI and SCGI.

j

 

[Paul Boddie]

I don't know much php either, but running a php app seems straight
forward enough.

I think that this (the ease of PHP application deployment) is one of
the things that keeps Python framework developers up at night,
regardless of whether the cause is technical (what processes or
components are running) or social (that hosting providers install
enough of the useful PHP stuff for people not to care about wanting to
install more).

Python seems to always use some sort of development environment vs
production environment scheme. For development, you are supposed to
run a local browser and load 127.0.0.1:5000 - or something like that.
Then to run the same thing in a development environment, I have to
configure some files, or touch all the files, restart the web-server,
or something. Why is that?

You can deploy Python Web applications using anything as simple as CGI
(which only requires a single change to the Web server setup), right
up to the full application server configuration. For a long time I've
advocated the ability to be able to do this without having to switch
frameworks and rewrite your code: that's what my WebStack package [1]
is all about, and I guess that given the availability of the right
adaptors and framework support, WSGI should let you do this as well.

Python also seems to require some sort of "long running processes" I
guess that the python interpretor has to running all of time.

Not so: deploying anything as a CGI script/program means that the
application code is only run when a request is made to the
application. Lots of Python software can use this approach: MoinMoin,
ViewVC, Trac... (All these things have, notably, implemented their own
mechanisms for abstracting away the deployment technology, since they
also work with things like mod_python. Another sad example of the
community not coalescing around standards, although I think they're
all looking into WSGI now.)

I am not really sure about what wsgi is supposed to accomplish.

It's supposed to decouple the deployment technologies from the
framework technologies, or at least that's what I'd use it for, and if
all frameworks supported it, you'd supposedly be able to take, say,
your Django application and run it on Zope 3, or your TurboGears
application and run it on Twisted. Of course, you'd write your Django
code differently from any Zope 3 code in your application, and the
TurboGears code wouldn't look a lot like Twisted code, but that's
another issue entirely.

Paul

[1] http://www.python.org/pypi/WebStack

 

[walterbyrd]

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.

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. 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.

 

[Paul Boddie]

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 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