6

新しいマシンを手に入れたばかりなので、新しいことに挑戦する機会を得ました。RVM は素晴らしく、私は gemsets を使用していますが、いくつかのブログ投稿を読んだ後、rbenv への切り替えを使用し、bundler を使用してRuby Rogues エピソード 45で概説されているように自分の gem を排他的に管理することにしました。

私はあまり共同作業をしません。共同作業をする場合は、通常、他の 1 人か 2 人と共同作業します。

バンドラーのドキュメントでは、次のコマンドを実行して gem をvendor/cacheディレクトリにパッケージ化する機能について詳しく説明しています。

$ bundle package
$ bundle install --local

ソース管理にチェックインできる優れた非公開の宝石。クリーンなサーバーへの展開やコラボレーションを容易にすることでしょうか?

Gemfileただし、 andGemfile.lockをソース管理にチェックインする場合、何が必要ですbundle packageか?

Ryan Mcgeary は2011 年初頭のこのブログ投稿でこのアプローチを提唱し、2010 年の別のブログ投稿で Yehuda Katz は次のように述べています。

バンドルされた gem を別の場所 (アプリケーション自体のディレクトリなど) にインストールしたい場合があります。これにより、各アプリケーションが独自の gem のコピーを持つことが保証され、追加レベルの分離が提供されます。

この分離は、gemset に非常に似ていると思います。システム gem の膨大なリストがある場合、アプリケーションで実際に使用されているのはどれかを知るのは難しいと想像できます。

では、gem をアプリケーションと一緒にパッケージ化しますか?

誰かがこれをやっていますか？この慣行は時代遅れですか？

アプリ内でジェムをバンドルすることのベスト プラクティスと利点/欠点は何ですか?

4

1 に答える 1

4

バンドル パッケージの使用例は限られていると思います。

Gemfile と Gemfile.lock はバージョン ロックを処理しますが、最終的にはバンドル インストールを行うときに ruby​​gems.org にアクセスして gem をダウンロードします。

バンドル パッケージが有用であることがわかる 3 つのシナリオ:

1) 私はクリーンな本番環境を持っており、rubygems.org には一切触れたくありません。これは、セキュリティ プロトコル、インターネット アクセスの制限などが原因である可能性があります。最終的に、サーバー環境やインターネットに実際に触れることなく、すべての宝石が並んで準備が整った、完全に自己完結型のアプリケーション パッケージができました。

2) gem をダウンロードして解凍し、いじって、その特定のものを使用したい。特に、git や fork などを扱いたくない場合はなおさらです。

3) 開発チームの観点からは、使用されるすべての gem がパッケージ化され、アプリに対してローカルである必要があると言えます。開発者が異なるバージョンをインストールしたり、環境に触れたりすることを心配する必要はありません。この理由は私の目にはやや弱いですが、このロジックを1、2回見たことがあります。

結局のところ、この能力を積極的に探しているユースケースがない限り、私はそれを避けます.

于 2013-01-13T18:24:34.973 に答える