Bundler: использование общего драгоценного камня, когда он существует, а не загрузка с драгоценного сервера

Скажем, у меня есть Gemfile, как показано ниже.

source "GEM_REPOSITORY"

gem 'gem_A'
# gem_A has no additional dependency

gem 'gem_B'
# gem_B depends on gem_B_1 and gem_B_2

Когда я запускаю bundle install, я хочу, чтобы Bundler делал следующее.

  1. Если гем уже существует в «локальных общесистемных гемах», он копирует гем из локального.

  2. Если гем не существует в локальном хранилище, он ищет GEM_REPOSITORY.

Я искал некоторые связанные статьи и нашел несколько вероятных ответов, таких как

Но ничего из вышеперечисленного не похоже на ответ для меня. Использование приоритета исходного репозитория не работает. Потому что в приведенном выше примере, если зависимый гем (скажем, gem_B_1) выходит из локального хранилища, но целевой гем (gem_B) не существует в локальном хранилище, он загрузит оба вышеперечисленных из удаленного репозитория.

Есть ли работа для этого? Если нет, не считаете ли вы это необходимым, учитывая стоимость внедрения и эффект?


ruby rubygems bundler gemfile gem
person Ryo    schedule 21.01.2015    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Это текущее поведение. При запуске gem install, напрямую или через bundle install, gem сначала построит граф зависимостей со всеми необходимыми драгоценными камнями. Если gem найден локально, он будет использовать его, в противном случае он попытается загрузить его из указанного источника.

Если хочешь, попробуй сам.

bundle gem gem_a
bundle gem gem_b
cd gem_a
vim gem_a.gemspec

добавлять

spec.add_dependency 'multi_json', '~> 1.10.1'

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

cd ../gem_b
vim Gemfile

и добавить

gem 'gem_a', path: '../gem_a'

затем беги

bundle install --verbose

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

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

person Daniel Perez    schedule 21.01.2015
comment
Похоже, это было мое недоразумение. Спасибо! - person Ryo; 21.01.2015