Управление конфликтующими версиями рубиновых самоцветов

Question

Я создаю фреймворк, который загружает предоставленный пользователем код ruby. Это в основном механизм плагинов. Я хочу, чтобы пользователь предоставлял код ruby, чтобы иметь возможность запрашивать собственные гемы. Я намерен включить в пакет «плагинов» каталог поставщиков с гемами.

Как я могу загрузить драгоценные камни, требуемые плагином, не конфликтуя с драгоценными камнями моей платформы? Например, если мой фреймворк использует treetop версии 1.3.0, а плагин использует treetop 1.4.2, я хочу, чтобы каждый работал с указанной версией.

Аналогично, есть ли способ предотвратить конфликты плагинов друг с другом?

Я посмотрел на gem_plugin, песочницу _why и некоторые другие инструменты. Но я не вижу ни одной библиотеки, которая бы конкретно занималась этим делом - я предполагаю, что это было сделано раньше.

Я также посмотрел на внутренние компоненты Bundler, чтобы увидеть, как он управляет версиями гемов. Я готов сделать несколько довольно сложных вещей, если это будет необходимо. Но я все еще не уверен, как это сделать.

У меня также есть большая свобода в том, как я это реализую. Поэтому, если вы думаете, что я лаю не на том дереве, скажите, пожалуйста.

Спасибо за любой совет.

СТОРОННОЕ ПРИМЕЧАНИЕ: Когда я писал это, мне пришло в голову, что мне нужно нечто похожее на загрузчики классов в контейнере сервлетов Java. Файл WAR может содержать файлы JAR, и загрузчик классов веб-приложения предпочтет те файлы, которые находятся в глобальном пути к классам. Есть ли в ruby ​​какой-либо способ сегментирования rub "classpath" (т.е. load_path, require и т. Д.)?

Answer 1

Если говорить прямо, нельзя одновременно загружать две версии одного и того же камня.

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

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

(Не начинайте меня с того, что разбираетесь с различными конкурирующими реализациями JSON и с какими трудностями вам приходится сталкиваться, когда у вас есть несколько зависимостей гемов, все из которых требуют разных.)

Answer 2

С уважением не согласен с ответом выше.Вот как я это делаю:

ruby -S gem list my_gem

`*** LOCAL GEMS ***
my_gem (1.0.1, 1.0.0, 0.0.2)
`

ruby -S gem lock my_gem-1.0.0 > locklist.rb

, который генерирует список зависимостей для конкретной версии в locklist

require 'rubygems'
gem 'my_gem', '= 1.0.0'
gem 'gem_base', '= 1.0.0'
gem 'rest-client', '= 1.7.2'
gem 'savon', '= 1.1.0'
gem 'addressable', '= 2.3.6'
gem 'mime-types', '= 1.25.1'
gem 'netrc', '= 0.11.0'

теперь вы можете сделать load('locklist.rb'), который загрузит конкретную версию гема вместе с его зависимостями.Смотри, ма, не Бандлер.