6

刚买了一台新机器，我借此机会尝试了一些新的东西。RVM 很棒，我一直在使用 gemsets，但在阅读了几篇博客文章后，我决定使用 switch 到 rbenv 并使用 bundler 来专门管理我的 gems，如Ruby Rogues 第 45 集所述。

我没有那么多合作，如果我这样做，通常是与其他一两个人合作。

vendor/cachebundler 文档详细说明了通过运行以下命令将 gem 打包到目录中的能力：

$ bundle package
$ bundle install --local

可以签入源代码控制的伟大的私人宝石；我猜想是部署到干净的服务器还是更容易协作？

但是，如果您检查Gemfile并Gemfile.lock进入源代码控制，那么需要bundle package什么？

Ryan Mcgeary 在 2011 年初的这篇博文和 2010 年的另一篇博文中提倡这种方法，Yehuda Katz 说：

您可能希望将捆绑的 gem 安装到不同的位置，例如应用程序本身的目录。这将确保每个应用程序都有自己的 gem 副本，并提供额外的隔离级别。

这种隔离很像我想的 gemsets，我可以想象当你有一个巨大的系统 gem 列表时，很难知道你的应用程序实际使用了哪些。

那么用应用程序打包宝石？

有人这样做吗？这种做法过时了吗？

在应用程序中捆绑 gem 的最佳做法是什么以及有哪些优点/缺点？

4

1 回答 1

4

我认为捆绑包的用例范围很窄。

Gemfile 和 Gemfile.lock 处理版本锁定，但最后你还是去 ruby​​gems.org 下载 gem 包安装。

我可以看到捆绑包有用的三个场景：

1）我有一个干净的生产环境，我根本不想碰rubygems.org。这可能是由于安全协议、有限的 Internet 访问等原因。最后，我有一个完全独立的应用程序包，其中所有的 gem 排成一行并准备就绪，而无需真正接触服务器环境或 Internet。

2）我想下载gem，解压它，搞定它，然后使用那个特定的。特别是如果我不想处理 git、forking 或任何类似的事情。

3) From a development team point of view, you can say that all gems being used must be packaged and local to the app. You wouldn't have to worry about developers installing different versions, touching their environments, etc. This reason is kinda weak in my eyes, but I've seen this logic once or twice.

In the end, unless you have a use case where you're actively hunting for this ability, I'd stay away from it.

于 2013-01-13T18:24:34.973 回答