Gemspec: Как я могу указать зависимости, которые не обязательно должны быть автоматическими?

Я написал драгоценный камень с определенным набором зависимостей, и некоторые из них я бы не хотел, чтобы они неявно требовались при объединении в другой проект. Примером может служить жемчужина uuidtools, которую я хочу использовать только в файлах.

gem.add_dependency("uuidtools",["=2.1.3"], :require => false)

Этот синтаксис является ложным, так как: require = > false там неожиданно, но это более или менее суммирует то, что я хотел бы сделать с ним. Может ли кто-нибудь помочь мне в этом?

Ответ 1

По умолчанию в ядре, указанном в файле gemspec для двигателей, требуется явно указать. Из официальной документации - Note that if you want to immediately require dependencies when the engine is required, you should require them before the engine initialization. В вашем случае вы должны иметь возможность получить что-то вроде gem.add_dependency 'uuidtools', '2.1.3' в вашем файле gemspec и потребовать в соответствующих местах.

Ответ 2

Я думаю, что способ выполнить то, о чем вы просите, это не поместить его в свой собственный gemspec, а вместо этого добавить Gemfile для bundler. Затем вы можете добавить его как драгоценный камень, установленный поставщиком.

Для этого добавьте простое слово "gemspec" в верхней части Gemfile или после деклараций источника. Это заберет драгоценные камни gemspec. Это, в принципе, не очень хороший дизайн. Это больше похоже на энтропию, которую вам следует избегать в драгоценных камнях и исходном коде, когда это возможно. Сказав, что я не думаю, что есть какой-либо вред, устанавливающий драгоценный камень и требующий его. Это должно быть правильно указано на именах и не будет мешать чему-либо еще.

Учитывая драгоценный камень, который вы цитируете. Возможно, вам больше не понадобится этот драгоценный камень. Вы на Ruby 1.9? Если это так, теперь есть модуль SecureRandom, встроенный в Ruby.

require 'secure_random'

my_uuid = SecureRandom.uuid

Вы можете сгенерировать с ним тоже UUID! Таким образом, ваши администраторы баз данных будут счастливы и могут использовать тип данных UUID в Postgres. (Вы используете postgres, правильно! Ха-ха). Также IIRC, UUIDTools не генерирует надлежащий UUID в соответствии со стандартами. Я считаю, что третья последовательность неверна.