[devel] ruby-rake и gems

[Mikhail Yakshin]

Kirill A. Shutemov wrote:

>>>Ну можно сделать симлинки или тривиальные rerequires. Примерно такие:
>>>
>>>/usr/share/ruby/vendor_ruby/1.8/activerecord.rb ->
>>>/usr/lib/ruby/gems/1.8/gems/activerecord-1.11.1/lib/active_record.rb
>>>
>>>Это даст возможность делать обычный require. Это решит вашу проблему?
>>
>>Если эти симлинки будут "опакечены" и не будут появляться "битые" симлинки, то 
>>ИМХО выглядит не так уж и страшно...
> 
> Если есть такая возможность, то почему бы вообще не разобрать gems по
> косточкам и не разложить в правильные директории (/usr/share/ruby/vendor_ruby/1.8/ 
> и т.п)? Оставить в /usr/lib/ruby/gems/1.8 только то, что нужно для
> require_gem (я так понял, что это /usr/lib/ruby/gems/1.8/specifications/*).

Например - потому, что gem тогда как package manager не будет его
видеть. Есть масса штуковин, которые работают уже в этой инфраструктуре.
Они ищут файлы по путям, отсчитывая их от базовый директории gem'а. Они
обращаются к Gem'у (а у него довольно развесистый API), с тем, чтобы
что-то узнавать о пакетах и потом действительно пользоваться этой
информацией. Автоматические тесты, что есть в gem'е - они будут искаться
именно в поддиректории test и т.п., причем, учитывая, что один пакет
зависит от другого - важно и их взаимное расположение и т.д. и т.п.

Вообще на самом деле - есть еще одно - простейшее, в общем-то, решение:
включить rubygems по умолчанию (ruby -rubygems). После этого начинают
автоматически работать require 'пакет' как синоним require_gem 'пакет'
(в дополнение к require 'файл') и остальные вещи, которые доступны в Gem
enviroment. При засовывании 'rubygems' в RUBYOPTS - всё, по сути, что
может не устраивать "противников" gem - это некий overhead в виде
микросекунд, которые требует загрузка этого самого Gem environment.
Может правда так сделаем и закроем вопрос?

-- 
WBR, Mikhail Yakshin AKA GreyCat