从第二次bundle install执行开始,只要未更改Gemfile,就会从Gemfile.lock加载依赖项.
但我想知道如何检测这两个文件之间的变化.
举例来说,如果我加入一个新的依赖直接进入Gemfile.lock的无添加入Gemfile中(而不是因为Gemfile.lock的最佳做法是从Gemfile中自动生成的),将一个bundle install考虑的Gemfile的改变?
实际上,bundle install进程是否会比较整个Gemfile和Gemfile.lock树以检测更改?
如果是,即使我直接向Gemfile.lock添加依赖项,Gemfile也会被检测为已更改(因为不同)并且会重新擦除Gemfile.lock(因此会丢失添加的依赖项...)
bundle install自第二次推出以来的过程是什么?
更清楚的是,我的问题是:
更改是否仅基于Gemfile?这意味着bundler会保留每个bundle install执行号N 的Gemfile快照,只是将它与bundle install执行N + 1 进行比较?
或者在bundler内存中没有创建快照,Bundler每次都会与Gemfile.lock进行比较,以检测是否必须将Gemfile视为已更改.
odi*_*apc 19
如果您编辑Gemfile.lock,那么Rails应用程序将依赖于其他版本的gem ...在这种情况下,gem-versioning系统的完整性将被破坏.直接编辑Gemfile.lock文件是一个非常糟糕的主意.
请成为一个好人,只与Gemfile达成交易
我知道这个问题已经很老了,但我最近不得不处理这个问题,所以我给出了自己的答案.Omniauth最近更新到版本1.3.2以修补安全问题.我的任务是将Omniauth更新到这个新的修补版本,但是在检查我们的Gemfile后,我意识到我们没有那个Gem.所以我说好吧也许我可以将Gemfile.lock上的版本从1.3.1切换到1.3.2.长话短说,这本来有用,但事实证明我不必这样做.我最终做的是发出以下命令
bundle update omniauth --patch
这导致了我手动进行的相同更改:
- omniauth (1.3.1)
+ omniauth (1.3.2)
Run Code Online (Sandbox Code Playgroud)
也就是说,如果您认为需要对Gemfile.lock进行更改,可能有一种方法可以在不触及Gemfile.lock本身的情况下进行更改.只是做bundle --help,你可能会找到并选择做你想要达到的目标.
| 归档时间: |
|
| 查看次数: |
5427 次 |
| 最近记录: |