对于新手来说，Python web framework VS. Rails两者间哪个的部署更容易些？且在出现问题时候更好解决些？

rails有capstrino很好用，挣扎上两次之后就可以很顺手了。

不过猜python也该有类似的东西

要稳妥的话还是PHP吧

好不好部署只是熟悉度的问题，不应该作为选择的考虑。
据我了解， Django 不是 Python 框架的首选。

BTW, 作为来自 Ruby 社区的人来说: “做 Web 选 Ruby on Rails，没错，就它了。”

rails 不适合新手，那么多magic

@ssword 昨天 Tx 在 ruby 北京技术聚会上分享，python 的部署工具没那么好用，相当于 cap 的每个过程都要自己写。

是不适合新手，每个新手都必将成为老手...

我觉得 PHP 部署比 Rails 难多了。得懂得 fcgi、nginx rewrite，我服务器上的 PHP 环境现在是完全忘了怎么配的了。

PS：刚才搜 PHP deploy 找到个有趣的东西 Automated PHP Deployment With Capistrano http://www.jonmaddox.com/2006/08/16/automated-php-deployment-with-capistrano/

@chloerei 真想当场听一下 :)
python的框架种类多，做出capistrano这样的部署工具也该没那么容易吧。

php的话，倒是很难想像没有migration都能怎么搞部署。

@chloerei PHP 让很多人觉得不难的原因是因为有 PHP 虚拟主机，FTP 上传就可以用了，连 Linux 都不需要

脱离具体场景比较哪个部署更容易，这个还是很有难度的。部署往往是一大堆纠结在一起的小问题。

PHP未必就真的最简单。尽管现实很可能是PHP最简单。


最简单的情况，就一台机器，跑一个apache，就只跑这一个应用。php可以用mod_php。python可以用mod_wsgi。ruby可以用mod_rack(就是那个Phusion Passenger)。这种部署方式，看上去这三者基本上没啥区别。

区别还是有的。

既然说到部署，肯定逃不掉发行版打包的问题。如果用的是Gentoo，那没有啥区别。如果用的是某些二进制发行版，还用的是比较老的那个，比如CentOS 5，你只能在EPEL里找到python 2.6的mod_wsgi，默认只有2.4的，有些地方可能会严禁使用第三方仓库的，而就算你用了EPEL，你还是找不到Passenger的。当然你也可以说，自己编译再打个包也很方便啊，换个发行版也不难啊。

PHP > Python > Ruby


接着扩展一下，别的不变，你现在跑两个独立的应用了。

这个时候需要权限隔离，不同的应用应该以不同的用户执行。我没有发现mod_wsgi有这样的功能。php可以用mod_suphp，Passenger声称php没有这样的功能，所以Passenger更安全，但是Passenger还要求apache以root执行，这个给人感觉就是好可怕，而mod_suphp，是用类似su的方式切换过去的。

PHP > Ruby >= Python


这种感觉很不好，所以进一步改进。一种看上去可行的方案是，改用supervisord来启动应用的进程，而http server用发行版自带的启动脚本启动。看上去配置文件还干净了不少。附带好处是每个应用可以在自己的目录下面安装需要的东西。但是有很多很多小问题等着你呢。不用supervisord，用别的，也依然会有类似的问题。这里把supervisord作为一个典型来讲。

1. apache的mod_proxy不能反向代理到unix socket，而mod_fcgid之类的模块，很多都有类似，直接全局有效而不是仅在某个域名下有效，这样的问题。lighttpd需要小心处理check-local、broken-scriptfilename、fix-root-scriptname这几个参数。nginx看上去很好，但是nginx的缺点是模块必须静态链接进去，如果没有你要的模块，那就悲剧了。cherokee FastCGI/SCGI之类的反向代理的行为和别的HTTP Server还有点不一样。

Apache < Others

2. php可能还好一点，就算用了spawn-fcgi或者php-fpm，php文件还是会自动重新加载？但是，有时候这不是你期望的，你只希望在你更新代码的时候重新加载。Python/Ruby做不到比较好的reload。且不说不能在Windows上运行，supervisord还有个问题，就是用命令行去操作的时候，只要你能连进去，你就有完全的权限。比较理想的情况是根据unix socket另一端的uid来决定能有那些权限。

PHP > Others

3. 静态文件的处理。因为放代码的目录默认除了运行该应用的用户，别的都不可读。静态文件得放在一个运行http server用户可读的目录里。这就要求框架或者部署工具能有一些基本的复制静态文件的能力。Django 1.3终于加上了collect_static。别的我不是很了解。谁了解的可以补充一下。


4. php可能一点问题都没有。Python可能很成问题，用supervisord里fcgi-program来启动应用的进程的时候，会从fd 0传入socket，只要你把这个socket设置成只是http server可读写的话，权限问题其实已经很干净了。但是，绝大部分非FastCGI协议的WSGI Server，都不支持这种方式启动。FastCGI看上去只有flup可用，而且就算是flup，SCGI协议还是不可以以这种方式启动，而且flup还有个很大的问题，就是不支持中文url。而且Python 2.x有个很尴尬的问题是在Windows上不支持socket.fromfd，其实是可以支持的，补丁也早就有了，目标版本都还是Python 2.6，可现在连Python 3都打上补丁了，2.x却没有，那个issue似乎彻底被遗忘了。谁了解Ruby/Rack的可以补充一下，感觉在这点上比Python好一点。

PHP > Ruby >= Python

5. 另外一个问题是库。前面提到的发行版的问题依然适用。不过有一点区别。php有不少库得编译，这样就麻烦了。Python有很多库即便提供了C Extension来提高运行速度，纯Python还是可以运行的。这样的库，Ruby比Python略少一些，导致在Windows下有时候会比较悲剧。当然，这个问题上，大家都比不过Perl的。

PHP <= Ruby <= Python < Perl



至于多台机器部署，以及其他的一些问题，有时间再来补充一下。

@bhuztez OMG, 牛x, web开发太难了，连部署都有那么多学问...