распаковка / заморозка драгоценных камней в приложении ruby без рельсов

Я пишу не-Rails-приложение ruby (задыхаясь!) И хотел бы иметь возможность включать все зависимости gem, которые требуются приложению, в подкаталог поставщика. Это было бы похоже на то, какhttp://gemsonrails.rubyforge.org/ работает для приложений Rails.

Цель здесь - избежать ситуации, в которой моя команда в настоящее время находится, когда добавляется новая зависимость. Каждый разработчик в моей команде должен установить гем вручную, а затем кто-то должен вручную обновить каждый тестовый, подготовительный и рабочий компьютер. Если мы сможем заморозить зависимости в самом распределенном приложении, то все, что нужно, - это простое обновление svn (или git pull для тех хипстеров в толпе).

Ответы на вопрос(1)

Решение Вопроса

UPDATE (New Solution):

Попробуйте новый Иегуда Кацпакетирования драгоценный камень.gem install bundler затем создатьGemfile со всеми вашими зависимостями. Смотрите документацию для получения дополнительной информации.

Old Recommendation:

Один простой способ - просто вручную распаковать драгоценные камни в свойvendor и добавьте путь lib распакованных гемов в начало $ LOAD_PATH.

Чтобы распаковать драгоценный камень:

$ cd vendor/gems
$ gem unpack active_support
Unpacked gem: '/path/to/myproject/vendor/gems/activesupport-2.3.2'

Просто убедитесь, что вы распаковали все необходимые гемы и их зависимости (используя правильные версии).

Чтобы добавить все драгоценные камни в vendor / gems к вашему $ LOAD_PATH, попробуйте добавить что-то вроде этого в инициализацию вашего приложения:

Dir.glob(File.join("vendor", "gems", "*", "lib")).each do |lib|
  $LOAD_PATH.unshift(File.expand_path(lib))
end

Update: Сара (в комментариях) убедила меня, что, возможно, также необходимо переопределить GEM_PATH. Вот один из способов сделать это:

require 'rubygems'
gem_paths = [File.expand_path(File.join("vendor", "gems")),  Gem.default_dir]
Gem.clear_paths
Gem.send :set_paths, gem_paths.join(":")

Другой вариант - заглянуть вПокойся с миром (Ruby & # x2019; s Intelligent Packaging) для управления вашими зависимостями. Рип выглядит очень мило, но все еще ново.

 10 июл. 2009 г., 20:10
Ах, хорошо, так что требуйте "some_gem" все равно будет работать, потому что some_gem / lib находится в $ LOAD_PATH. Это интересный подход.
 10 июл. 2009 г., 20:29
Сара, ага, здесь возможная проблема, хотя. Если драгоценный камень используетgem способ загрузить драгоценный камень вместоrequire, где могут возникнуть проблемы и где может потребоваться GEM_PATH.
 10 июл. 2009 г., 20:12
Тем не менее, если использование драгоценного камня требует 'rubygems' чтобы найти другой драгоценный камень (как это делают многие), у вас проблемы.
 10 июл. 2009 г., 21:20
Интересно - я не знал, что RubyGems использует $ LOAD_PATH до GEM_PATH. В дополнение к Rip есть также новый упаковщик Yehuda и Carl:yehudakatz.com/2009/07/08/rails-bundling-revisited
 Pete Hodgson12 июл. 2009 г., 09:22
Оказывается, что данное решение не совсем подходит для всех драгоценных камней. В частности, я использую database_cleaner (github.com/bmabey/database_cleaner), который при распаковке содержит файл vendor / gems / bmabey-database_cleaner-0.2.2 / examples / lib / activerecord.rb. Dir.glob, приведенный в ответе Райана, приводит к тому, что activerecord.rb предпочтительнее, чем камень activerecord activerecord.rb. Я настроил Dir.glob, данный для использования & apos;' rather than '*& APOS; и все было хорошо, по крайней мере, для моего набора драгоценных камней. YMMV.

Ваш ответ на вопрос