Rip 是一个 GitHub 团队开发的全新的 Ruby 包管理系统。它能够管理不同的安装源，例如目录、文件，Git 版本库以及 RubyGems 等。
另外一个有趣的新特性是虚拟环境（“ripenvs”）。Ripenvs 能够用于无冲突地安装和管理一个包的多个版本。Ripenvs 能够使得依赖库的升级更加安全，方法很简单，只需通过创建一个新的实验环境然后在这个环境中升级即可，如果中途发生任何意外，你也能够回到之前稳定的环境。
但是为什么是一个全新的包管理器？RubyGems 怎么了？我们采访了 Rip 开发者之一，Chris Wanstrath：
RubyGems 没有任何什么问题。我很喜欢 RubyGems。看起来人们认为 Rip 是“修正”或者是补充 RubyGems。但是事实并不是这样。 Rip 的目的是使得包的安装、使用和管理更加快捷方便。它的目标人群是安装者而不是分发者；是那些能够通过命令准确知道应用程序所使用的库版本的用户，而不是那些需要猜测库版本的用户；是那些希望在安装包的时候希望知道发生了依赖冲突的用户，而不是对此漠不关心的用户。
Rip 是为那些希望能够主动知道运行 X 的版本的用户编写的。这也是在帮助你调试一个问题。希望能够保证所有计算机都运行着相同版本的相同库的用户可以使用这个工具。还有那些希望看到升级某个库的影响如何的用户也可以使用这个工具。
Rip 不是寻找其他系统的缺点而是优点。
仅仅使用 RubyGems 是否会更加容易一些呢？
Rip 和 RubyGems 是两个迥异的工具： - Rip 和你的 $LOAD_PATH 相关，而 RubyGems 则是重载了‘require’。
- Rip 关注于 $RUBYLIB 而 RubyGems 需要一个‘require “rubygems”’。
- Rip 能够管理多个环境，每个环境的库的版本是独立的，而 RubyGems 只能管理一个单独的环境，每个库可能有多个版本。
- Rip 能够（理论上）安装任何包类型，而 RubyGems 只能安装.gem 文件。
所以，它们真的是不同的项目，关注于不同的东西。我不相信它将会在工作的时候（或者部分），完全改变 RubyGems 的目标、核心理念和基础代码。这两个系统能够和谐共处。
虚拟环境貌似是管理为不同版本 Ruby 编写的包的完美解决方案，例如 JRuby。
当然，这也是 Rip 优点所在——也许你需要为不同版本的 Ruby 发布不同版本的 ripenvs（可安装的 Rip 虚拟环境）。一个是为 1.9，一个是为 1.8，一个是为 JRuby——使用 Rip 对你和你的客户来说都更加容易。 这就是 Rip 工作的方式。不需要任何特别的特性。
Rip 现在仅仅是发布了 0.0.1 版，你们接下来打算做些什么呢？
我们还没有开始升级甚至是深入了解 ripenvs 的能力。能够使用一个命令（例如 ‘rip freeze | gist ’）来共享开发环境，合并开发环境而不用担心版本冲突。使用 ripenvs 部署你的应用程序仅仅是我们的目标之一。 我们也希望能够复制 git 的‘reflog‘思想，所以你能够轻易地检视或者撤销任何你在 ripenv 中所作的更改。你不需要担心任何数据或者设置的丢失。
我们也有一些比较大的想法，比如能够帮助你根据名字而不是 url 找到包。
当然，支持 hg、svn 和 bzr 是计划之内的事情。你需要安装它们。
我们也会在 Rip 1.0 中支持 Windows。
更多 Rip 的信息，包括一个简短的教程请参见 Rip website 。
评论