tl;dr
- Bundler v1.10.0からBUNDLED WITHのsectionが導入された。
- restore_bundled_withを使うことで、Bundler開発チームの精神を逸脱して(!)、異なるversionのBundlerとBUNDLED WITHをうまく取り扱う。
Bundler v1.10 とBUNDLED WITH
Bundler v1.10.0からBUNDLED WITH
というsectionにbundle update
を実行したBundlerのversionを
記録するようになった。
日本語詳細はこちらが詳しい。
Ruby - BUNDLED WITH で Gemfile.lock が更新されてしまう件 - Qiita
挙動の確認
Bundler v1.10.2でbundle update
して、BUNDLED WITHにversionを記録しておく。
Bundler v1.9.9で bundle update
BUNDLED WITHのsectionごと消える。悲しい。
Bundler v1.10.4(新しい)で bundle update
BUNDLED WITHの記録を更新する。
Bundler v1.10.1(古い)で bundle update
Warning出しつつ、BUNDLED WITHは更新しない。
正しい解
まずは、Bundlerのversionをv1.10系の最新版に上げる。 そして、依存ライブラリのバージョンを上げていくと同時にBundlerも最新版が出るたびに上げていく。
現実解?
- そうは言っても、localではpreとかv2とか新しすぎるものも使いたい。
- 実際にproductionで実行するBundlerのversionと離れてしまいかねないのはいつか問題になりそう。
- Gemfileの中はBundler管轄だけど、Bundler自体はそこで管理してないわけで、lockの記述に引きずられるのはどうなんだろう(私見)
- minimalなbundlerのmini_bundler(仮)が薄くいて、bundle execなどのコマンドはその内側でバージョン管理されたbundlerで実行すればいい?(私見)
などの理由から、Bundler開発チームの精神を逸脱して(!)、restore_bundled_withというgemのrestore-bundled-with
コマンドを使う。
restore_bundled_with
Gemfile.lock
のBUNDLED WITHにリポジトリとdiffがある状態で、restore-bundled-with
コマンドを実行する。
つまり、bundle update
したあと、commitする前に、restore-bundled-with
する。
すると、リポジトリからBUNDLED WITHのsectionを取り出してきて、そこだけ元に戻る。
Bundler v1.9なら、消えたsectionが戻る。 より新しいBundler v1.10なら、使った記録がそこだけ戻る。
Example
Newer Bundler Case
Execute bundle update
by Bundler v1.10.3.
Then, execute restore-bundled-with
.
There is no diff, because this restores BUNDLED WITH
from git repository.
まとめ
Bundler開発チームの精神を逸脱するので、あまり推奨はしない。 最新版を使って、もし壊れていたらみんなで直していくのが、アプリケーションを健全に保つ一番痛みが少ない方法なのです!
詰まったら聞いてください。このサイトやREADMEなどに反映します。 ruby-restore_bundled_withにスターください!