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
