bundle-install - Установите зависимости, указанные в вашем Gemfile
bundle install [--binstubs[=DIRECTORY]] [--clean] [--deployment] [--frozen] [--full-index] [--gemfile=GEMFILE] [--jobs=NUMBER] [--local] [--no-cache] [--no-prune] [--path PATH] [--quiet] [--redownload] [--retry=NUMBER] [--shebang] [--standalone[=GROUP[ GROUP...]]] [--system] [--trust-policy=POLICY] [--with=GROUP[ GROUP...]] [--without=GROUP[ GROUP...]]
Установите гемы, указанные в вашем Gemfile(5). Если вы впервые запускаете установку пакета (и Gemfile.lock не существует), Bundler извлечет все удаленные источники, разрешит зависимости и установит все необходимые драгоценные камни.
Если Gemfile.lock существует, а вы не обновили свой Gemfile(5), Bundler извлечет все удаленные источники, но будет использовать зависимости, указанные в Gemfile.lock. вместо разрешения зависимостей.
Если Gemfile.lock существует и вы обновили свой Gemfile(5), Bundler будет использовать зависимости в Gemfile.lock для всех гемов, которые вы не обновляли. , но повторно разрешит зависимости гемов, которые вы обновили. Дополнительную информацию об этом процессе обновления можно найти ниже в разделе КОНСЕРВАТИВНОЕ ОБНОВЛЕНИЕ.
--очистить, --развернуть, --заморозить, --не удалять, --path, --shebang, --system, --без и --с параметры устарели, потому что они имеют смысл только в том случае, если они применяются к каждой последующей установке пакета, выполняемой автоматически, и это требует, чтобы комплектировщик молча запоминал их. Поскольку bundler больше не будет запоминать флаги CLI в будущих версиях, bundle config (см. bundle-config(1)) следует использовать для их постоянного применения.
Binstub — это скрипты, которые оборачивают исполняемые файлы. Bundler создает небольшой файл Ruby (binstub), который загружает Bundler, запускает команду и помещает ее в bin/. Это позволяет вам связать binstub внутри приложения с точной версией gem, необходимой приложению.
Создает каталог (по умолчанию ~/bin) и помещает туда все исполняемые файлы из драгоценного камня. Эти исполняемые файлы запускаются в контексте Bundler. Если он используется, вы можете добавить этот каталог в переменную PATH вашей среды. Например, если гем rails поставляется с исполняемым файлом rails, этот флаг создаст исполняемый файл bin/rails, который гарантирует, что все указанные зависимости будут быть решены с помощью связанных драгоценных камней.
По завершении установки Bundler удалит все драгоценные камни, отсутствующие в текущем Gemfile(5). Не волнуйтесь, драгоценные камни, используемые в настоящее время, не будут удалены.
Этот параметр устарел и заменен на параметр clean.
В режиме развертывания Bundler «развернет» пакет для производства или использования в CI. Внимательно проверьте, хотите ли вы, чтобы эта опция была включена в вашей среде разработки.
Этот параметр устарел и заменен параметром deployment.
Принудительно загружать каждый гем, даже если требуемые версии уже доступны локально.
Не позволяйте Gemfile.lock обновляться после этой установки. Выход ненулевой, если в Gemfile.lock будут внесены изменения.
Этот параметр устарел и заменен на параметр замороженный.
Bundler не будет вызывать конечную точку API Rubygems (по умолчанию), а загрузит и кэширует (в настоящее время большой) индексный файл всех драгоценных камней. Включив этот параметр, можно повысить производительность для больших пакетов, которые редко изменяются.
Расположение Gemfile(5), которое должен использовать Bundler. По умолчанию это Gemfile(5) в текущем рабочем каталоге. Как правило, Bundler предполагает, что местоположение Gemfile(5) также является корнем проекта, и пытается найти Gemfile.lock и vendor/cache относительно этого местоположения. .
Максимальное количество параллельных заданий загрузки и установки. По умолчанию используется количество доступных процессоров.
Не пытайтесь подключиться к rubygems.org. Вместо этого Bundler будет использовать гемы, уже имеющиеся в кеше Rubygems или в vendor/cache. Обратите внимание: если на rubygems.org существует соответствующий гем для конкретной платформы, он не будет найден.
Принудительно использовать локально установленные гемы или гемы, уже присутствующие в кеше Rubygems или в vendor/cache, при разрешении, даже если более новые версии доступны удаленно. Пытайтесь подключиться к rubygems.org только для драгоценных камней, которых нет локально.
Не обновляйте кеш в vendor/cache с помощью новых связанных гемов. Это не удаляет какие-либо драгоценные камни в кеше, но предотвращает кеширование новых связанных драгоценных камней во время установки.
Не удаляйте устаревшие драгоценные камни из кеша после завершения установки.
Этот параметр устарел и заменен на параметр no_prune.
Место для установки указанных гемов. По умолчанию используется настройка Rubygems. Bundler разделяет это расположение с Rubygems, gem install ... также будет иметь установленный там gem. Таким образом, gem-пакеты, установленные без параметра --path..., будут отображаться при вызове gem list. Соответственно, драгоценные камни, установленные в других местах, не будут перечислены.
Этот параметр устарел и заменен параметром path.
Не выводить информацию о ходе выполнения на стандартный вывод. Вместо этого Bundler завершит работу с кодом состояния ($?).
Повторите неудачные сетевые или Git-запросы количество раз.
Использует указанный исполняемый файл ruby (обычно ruby) для выполнения скриптов, созданных с помощью --binstubs. Кроме того, если вы используете --binstubs вместе с --shebang jruby, эти исполняемые файлы будут заменены на выполнение jruby.
Этот параметр устарел и заменен параметром shebang.
Создает пакет, который может работать независимо от Rubygems или Bundler во время выполнения. Должен быть указан разделенный пробелами список групп для установки. Bundler создает каталог с именем bundle и устанавливает в него пакет. Он также создает файл bundle/bundler/setup.rb для замены собственной установки Bundler требуемым образом. Использование этого параметра неявно задает путь, который является [запоминаемым параметром][ЗАПОМНЕННЫЕ ОПЦИИ].
Устанавливает драгоценные камни, указанные в пакете, в системное расположение Rubygems. Это переопределяет любую предыдущую настройку --path.
Этот параметр устарел и заменен на системный.
Примените политику безопасности Rubygems policy, где политика имеет значение HighSecurity, MediumSecurity, LowSecurity, Почти без безопасности. или Без защиты. Дополнительные сведения см. в документации по подписанию Rubygems, ссылка на которую приведена ниже в разделе СМ. ТАКЖЕ.
Разделенный пробелами список групп, ссылающихся на гемы для установки. Если задана необязательная группа, она установлена. Если задана группа, которая находится в запомненном списке групп, указанном --without, она удаляется из этого списка.
Этот параметр устарел, вместо него используется параметр with.
Разделенный пробелами список групп, ссылающихся на драгоценные камни, которые следует пропустить во время установки. Если задана группа, которая находится в запомненном списке групп, указанном --with, она удаляется из этого списка.
Этот параметр устарел и заменен на параметр без.
Значения по умолчанию Bundler оптимизированы для разработки. Чтобы переключиться на значения по умолчанию, оптимизированные для развертывания и непрерывной интеграции, используйте флаг --deployment. Не активируйте режим развертывания на машинах разработки, так как это вызовет ошибку при изменении Gemfile(5).
Требуется Gemfile.lock. Чтобы убедиться, что одни и те же версии гемов, с которыми вы разрабатывали и тестировали, также используются в развертываниях, требуется Gemfile.lock. В основном это делается для того, чтобы вы не забыли проверить свой Gemfile.lock в системе контроля версий.
Gemfile.lock должен быть обновлен. В процессе разработки вы можете изменить Gemfile(5) и повторно запустить установку пакета, чтобы консервативно обновить моментальный снимок Gemfile.lock. При развертывании ваш Gemfile.lock должен быть обновлен с учетом изменений, внесенных в ваш Gemfile(5).
Gems устанавливаются в папку vendor/bundle, а не в вашу системную папку по умолчанию. При разработке удобно делиться гемами, используемыми в вашем приложении, с другими приложениями и другими скриптами, работающими в системе. При развертывании изоляция является более важным параметром по умолчанию. Кроме того, у пользователя, развертывающего приложение, может не быть разрешения на установку драгоценных камней в систему, или у веб-сервера может не быть разрешения на их чтение. В результате bundle install --deployment устанавливает гем в каталог vendor/bundle в приложении. Это можно переопределить с помощью параметра --path.
По умолчанию bundle install установит все гемы во всех группах в вашем Gemfile(5), за исключением тех, которые объявлены для другой платформы.
Однако вы можете явно указать Bundler пропускать установку определенных групп с помощью параметра --without. Эта опция принимает список групп, разделенных пробелами.
Хотя параметр --without пропускает установку гемов в указанных группах, он по-прежнему загружает эти геморы и использует их для разрешения зависимостей. каждого драгоценного камня в вашем Gemfile(5).
Это сделано для того, чтобы установка другого набора групп на другом компьютере (например, на производственном сервере) не изменила гемы и версии, которые вы уже разработали и протестировали.
Bundler предлагает надежную гарантию того, что сторонний код, который вы используете при разработке и тестировании, также является сторонним кодом, который вы используете в рабочей среде. Вы можете исключить часть этого кода в разных средах, но вы никогда не застанете себя врасплох из-за того, что разные версии стороннего кода используются в разных средах.
В качестве простой иллюстрации рассмотрим следующий Gemfile(5):
source 'https://rubygems.org'
gem 'sinatra'
group :production do
gem 'rack-perftools-profiler'
endВ этом случае sinatra зависит от любой версии Rack (>= 1.0), а rack-perftools-profiler зависит от 1.x ( ~> 1.0).
Когда вы запускаете bundle install --without production в процессе разработки, мы также смотрим на зависимости rack-perftools-profiler. Таким образом, вы не тратите все свое время на разработку для Rack 2.0, используя новые API, недоступные в Rack 1.x, только для того, чтобы Bundler переключился на Rack 1.2, когда производственная группа собирается используется.
На практике это не должно вызвать никаких проблем, потому что мы не пытаемся установить драгоценные камни в исключенных группах, а только оцениваем их как часть процесса разрешения зависимостей.
Это также означает, что вы не можете включать разные версии одного и того же гема в разные группы, потому что это приведет к тому, что при разработке и производстве будут использоваться разные наборы зависимостей. Из-за капризов процесса разрешения зависимостей это обычно влияет не только на гемы, которые вы перечисляете в своем Gemfile(5), и может (на удивление) радикально изменить используемые вами гемы.
Когда вы запускаете bundle install, Bundler сохраняет полные имена и версии всех используемых вами гемов (включая зависимости гемов, указанных в Gemfile(5)) в файле с именем Gemfile. заблокировать.
Bundler использует этот файл во всех последующих вызовах bundle install, что гарантирует, что вы всегда используете один и тот же точный код, даже когда ваше приложение перемещается между компьютерами.
Из-за того, как работает разрешение зависимостей, даже, казалось бы, небольшое изменение (например, обновление точечного выпуска зависимости гема в вашем Gemfile(5)) может привести к тому, что для удовлетворения всех зависимостей потребуются совершенно разные гемы.
В результате вы ДОЛЖНЫ проверить свой Gemfile.lock в системе контроля версий как в приложениях, так и в гемах. Если вы этого не сделаете, каждая машина, которая проверяет ваш репозиторий (включая ваш рабочий сервер), будет снова разрешать все зависимости, что приведет к использованию разных версий стороннего кода, если какой-либо драгоценный камень в Gemfile(5) или любая из его зависимостей были обновлены.
При первом выпуске Bundler файл Gemfile.lock был включен в файл .gitignore, входящий в состав сгенерированных гемов. Однако со временем стало ясно, что эта практика перекладывает боль сломанных зависимостей на новых участников, в то время как существующие участники потенциально не знают о проблеме. Поскольку установка пакета обычно является первым шагом на пути к вкладу, проблемы с неработающими зависимостями отбивают у новых участников желание вносить свой вклад. В результате мы пересмотрели наше руководство для авторов гемов, и теперь мы рекомендуем проверять блокировку на наличие гемов.
Когда вы вносите изменения в Gemfile(5), а затем запускаете bundle install, Bundler обновит только измененные вами гемы.
Другими словами, если гем, который вы не изменяли, работал до того, как вы вызвали установку пакета, он продолжит использовать те же самые версии всех зависимостей, которые использовались до обновлять.
Давайте посмотрим на пример. Вот ваш оригинальный Gemfile(5):
source 'https://rubygems.org'
gem 'actionpack', '2.3.8'
gem 'activemerchant'В этом случае и actionpack, и activemerchant зависят от activesupport. Гем actionpack зависит от activesupport 2.3.8 и rack ~> 1.1.0, а гем activemerchant зависит на activesupport >= 2.3.2, braintree >= 2.0.0 и builder >= 2.0.0.
Когда зависимости будут впервые разрешены, Bundler выберет activesupport 2.3.8, который удовлетворяет требованиям обоих гемов в вашем Gemfile(5).
Затем вы изменяете свой Gemfile(5) на:
source 'https://rubygems.org'
gem 'actionpack', '3.0.0.rc'
gem 'activemerchant'Гем actionpack 3.0.0.rc имеет ряд новых зависимостей и обновляет зависимость activesupport до = 3.0.0.rc, а Зависимость rack от ~> 1.2.1.
Когда вы запускаете bundle install, Bundler замечает, что вы изменили гем actionpack, но не гем activemerchant. Он оценивает драгоценные камни, которые в настоящее время используются для удовлетворения его требований:
также используется для удовлетворения зависимости в activemerchant, которая не обновляется
в настоящее время не используется для удовлетворения другой зависимости
Поскольку вы явно не просили обновить activemerchant, вы не ожидаете, что он внезапно перестанет работать после обновления actionpack. Однако для удовлетворения новой зависимости activesupport 3.0.0.rc пакета действий требуется обновить одну из его зависимостей.
Несмотря на то, что activemerchant объявляет очень свободную зависимость, которая теоретически соответствует activesupport 3.0.0.rc, Bundler рассматривает драгоценные камни в вашем Gemfile(5), которые не изменились, как атомарную единицу вместе. со своими зависимостями. В этом случае зависимость activemerchant рассматривается как activemerchant 1.7.1 + activesupport 2.3.8, поэтому установка пакета сообщит, что не может обновить пакет действий.
Чтобы явно обновить actionpack, включая его зависимости, от которых все еще зависят другие gem-пакеты в Gemfile(5), запустите пакет обновления actionpack (см. bundle update(1)).
Вывод. Как правило, после внесения изменений в Gemfile(5) вы должны сначала попытаться запустить установку пакета, что гарантирует, что никакой другой гем в Gemfile( 5) затронуты изменения. Если это не сработает, запустите пакет обновления(1) bundle-update.1.html.
Документация по установке Gem http://guides.rubygems.org/rubygems-basics/#installing-gems
Rubygems подписывает документы http://guides.rubygems.org/security/