刚拿到一台新机器后，我抓住机会尝试新的东西。 RVM非常好，我一直在使用gemsets，但在阅读了一些博客文章后，我决定使用切换到rbenv并使用bundler来专门管理我的宝石，如Ruby Rogues episode 45中所述。
我没有那么多合作，如果我这样做，通常只有一两个人。
Bundler文档详细说明了通过运行以下方法将宝石打包到vendor/cache目录的能力：
$ bundle package
$ bundle install --local
可以检入源代码控制的优秀私人宝石;我想部署到干净的服务器或协作更容易吗？
但是，如果您将Gemfile和Gemfile.lock检入源代码管理中，那么bundle package需要什么？
Ryan Mcgeary在2011年初以blog post形式倡导这种方法，并在2010年的另一个blog post中提倡Yehuda Katz说：
您可能希望将捆绑的gem安装到其他位置，例如应用程序本身中的目录。这将确保每个应用程序都有自己的宝石副本，并提供额外的隔离级别。
这种隔离就像我猜想的宝石一样，我可以想象当你拥有庞大的系统宝石列表时，很难知道你的应用程序实际使用了哪些宝石。
有人这样做吗？这种做法过时了吗？
在应用程序中捆绑宝石的最佳做法是什么？优点/缺点是什么？
答案 0 :(得分：4)
我认为捆绑包有一小组用例。
Gemfile和Gemfile.lock处理版本锁定，但最后你仍然会去rubygems.org并在你进行捆绑安装时下载gem。
我可以看到捆绑包有用的三个场景：
1）我有一个干净的生产环境，我根本不想触摸rubygems.org。这可能是由于安全协议，有限的互联网访问等等。最后，我有一个完全独立的应用程序包，所有的宝石排成一行，准备就绪，没有真正触及服务器环境或互联网。 / p>
2）我想下载宝石，打开包装，拧上它，并使用那个特定的宝石。特别是如果我不想处理像git，orking或者任何东西这样的东西。
3）从开发团队的角度来看，您可以说所有正在使用的宝石必须打包并且应用程序是本地的。您不必担心开发人员安装不同版本，触摸他们的环境等等。这个原因在我看来有点弱，但我已经看过一两次这样的逻辑。
最后，除非你有一个使用案例，你正在积极寻找这种能力，否则我会远离它。