On 30 Jan, 21:27, walterbyrd <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
