ПРИМЕЧАНИЕ. Я написал весь ответ, предполагая, что вы используете Bundler для управления своими гем-зависимостями. Я понимаю, что некоторые люди этого не делают, и вы не упомянули Бандлера в своем вопросе. Если вы не используете Bundler, я бы отметил, что это, вероятно, лучший способ экономии дискового пространства (хотя, если вы bundle install --system, хотя!). Если вы используете экспортированные наборы гемс для управления зависимостями, я думаю, что ваша схема звучит разумно, но у меня нет опыта работы с ней.
Как Rails 3, так и Rails 2 с Bundler установят свой путь загрузки соответствующим образом, чтобы они не загружали какие-либо драгоценные камни (или любые версии любых драгоценных камней), которых нет в Gemfile.lock. На самом деле я не сталкивался с проблемой зависимости от гемов на сервере. Важно, чтобы вы запускали bundle install на своем компьютере разработчика всякий раз, когда вы изменяете Gemfile, и вы проверяете Gemfile.lock в управлении исходным кодом, как описано на домашней странице Bundler .
Я потратил некоторое время, копаясь в сценариях использования наборов гемов назад в январе . Причины, по которым я обнаружил использование отдельных наборов гемс для каждого проекта:
- Ваша оболочка такая же, как и ваша прикладная среда (скрипты работают без
bundle exec).
- Вы можете легко просматривать и просматривать исходный код всех ваших зависимостей, перейдя в каталог установки gemset.
- По словам автора RVM, он предотвращает некоторые сообщения о "гейзенгах". Я испытал нечто подобное, когда исполняемый файл gem не был доступен, и
bundle exec, похоже, не помогло.
Я не думаю, что какое-либо из этих преимуществ на сервере очень выгодно, поэтому, если вы хотите сэкономить место на диске, я не уверен, зачем вообще использовать gemsets.
На самом деле единственная причина, по которой я вообще использовал rvm на сервере, заключалась в том, что это был удобный способ создания ruby из исходного кода (нам была нужна версия, которая не была доступна в собственном менеджере пакетов).