12 November 2014

OS X系统与Linux系统一样,底层的基础都是Unix。这意味着为Linux开发的各种命令行程序也能在OS X上使用。我们固然可以从这些程序的源码来生成它们, 但更方便的途径是像其他Linux发行版一样,使用一个程序包管理工具(如Ubuntu上的apt或者RedHat上的yum)。

OS X官方没有提供这样的工具,但第三方的却出现过不少。经过大浪淘沙,目前存活下来的(或者说使用人数最多的)有两个:MacPortsHomebrew

那么问题来了:用哪个?(我这么正经的人怎么会扯到挖掘机!)

我本来不用这种工具的。需要什么程序时,还真就像上面说的那样,自己从源码编译安装(这才是真正的Geek好不好!)。 不过当我要在Mac上使用ant时,我终于决定采用包管理工具来安装它了。于是MacPorts还是Homebrew的问题不可避免地摆在了我面前。

我最终选择了MacPorts。

首先从命名上,我觉得MacPorts名正言顺。从这个名字可以直观看出其目的是向Mac移植程序。但Homebrew是啥?它的作者说自己喜欢在家酿啤酒,所以就用“家酿(homebrew)”来给作品取名了。 这虽然也蛮有意思,但我更喜欢名正言顺。不过这都是个人品味的问题了,说不定有人觉得Homebrew要酷得多呢。

其次,MacPorts比Homebrew历史久远。与前者相比,后者只是个小孩子。这一方面使得MacPorts支持更多的程序,另一方面也显得更靠谱,毕竟久经了考验。但是,新项目有新项目的优势。 例如:Homebrew用git作为版本管理,项目代码托管在GitHub上,这都代表了流行趋势,也使其能迅速发展;Homebrew的主页明显比MacPorts现代化一些。所以新进入这一领域(Mac上的程序包管理工具)的人, 可能会更容易被Homebrew吸引。我之所以没被这些优势打动,仍旧选择MacPorts,说实话是抵制了诱惑的。

最后,就来说说真正让我抵制住诱惑、选择了MacPorts的原因:

  1. MacPorts会将文件放在自己新建的专属目录下(/opt/local/),Homebrew则简单地把文件放在/usr/local/目录下。/usr/local/是大多数别的程序安装的默认位置,于是Homebrew管理的程序就会和我自己安装的程序混在一起。 相对而言,我觉得分离管理是更好的选择。

  2. MacPorts在/opt/local/目录下维护了一套独立的程序体系。这样不管系统如何更新变动,它都不受影响。而Homebrew则调用了系统中的程序,这使得它对外部环境产生依赖。 比如最近OS X升级,就导致Homebrew立即不能用了(网上出现了一大批讨论如何让它重新能用的文章)。维护独立程序体系也有代价,就是需要额外下载系统已有的程序,费时又费空间; 不过随着这个子系统渐渐完善,很快费时这个缺点就没了,而稳定可用这一优势就突显出来。

事实上,Homebrew也在改变它的策略,例如不再把文件直接放在/usr/local/了,而是也放在自己的专属目录下,只是在/usr/local/下创建符号链接。 作为一个新项目,Homebrew在不断进步,或许可以融合MacPorts的优势,最终超越它的前辈。

MacPorts本身是传统的C程序,而Homebrew是用Ruby写的。网上有人在比较这两个项目时指出,现在用Ruby或Python或Perl或别的什么脚本语言的那帮人,总喜欢用这些新的语言搞出自己的一套平台, 然后在基于C语言的Unix上面铺一层中间件(先要安装这些脚本语言的解释器)。有了MacPorts还要搞个Homebrew,到底是重复造轮子,还是具有新的价值?这或许也是仁者见仁智者见智的事情吧。

所以用MacPorts,也有向传统致敬的意思。