ruby-on-rails – Rails 3的“捆绑安装”和“捆绑安装 – 部署”都能很好地运行,第二个只是使用更多的磁盘空间?

前端之家收集整理的这篇文章主要介绍了ruby-on-rails – Rails 3的“捆绑安装”和“捆绑安装 – 部署”都能很好地运行,第二个只是使用更多的磁盘空间?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
似乎在开发机器(如Macbook)上,如果我们使用bundle install -deployment,那么所有的gem都将被安装到vendor / bundle文件夹中,如果我们有多个Rails 3项目(一些项目只是为了测试Rails 3).如果不是–deployment,那么宝石将在“通用”文件夹中,而不是在项目文件夹内,因此可以跨项目共享.这是真的?

另一件事是,我们需要将vendor / bundle下的所有文件添加到我们的存储库并推送它吗?看来,如果我们这样做,我们只是阻止回购,因为如果我们不这样做,所有适当的宝石将通过捆绑安装使用Gemfile.lock中指定的所有宝石进行安装. (Gemfile.lock是repo中的一个小文件).这是真的吗

解决方法

是!真正.

当您使用–deployment标志时,Bundler确保您需要的每个gem都将被销毁,即它们被复制到预定位置,您的应用程序的文件夹结构(这恰好是Rails中的供应商/捆绑包),这对于两件事情是有好处的.

首先,如果您的权限有限,阻止您在部署机器中安装宝石,那么让您拥有应用程序所需的所有宝石.

第二,如果你想要挖掘宝石中的实际代码,你可以这样做,而不影响系统的宝石.您所做的更改只会影响您正在处理的应用程序.

这种使用方法有另一种用途,即确保您正在使用特定版本的宝石,并且即使系统宝石升级到可能会破坏您的应用程序的更高版本,您的应用程序也会继续工作.但是,Bundler本身使得这种用例大部分已经过时,因为它自动安装和引用了特定版本的宝石.

是的,售货将会膨胀你的应用程序的代码. Gemfile.lock只是所需宝石的列表.如果您提供宝石,他们将尽可能复制到您的应用程序.

所以,我建议你不要供应你的宝石(这也意味着不要使用–deployment标志),除非你有上述原因之一.

猜你在找的Ruby相关文章