Узнайте бандлер получше
Бандлер оказался замечательным средством установки и отслеживания джемов, которое так нужно каждому руби проекту настолько, что почти каждый проект использует его. Однако, несмотря на его повсеместность, большинство пользователей не знают о встроенных средствах и помощниках бандлера. В попытке повысить осведомленность (и производительность Руби разработчиков), я собираюсь рассказать вам о них.
Install, update, и outdated
Вы наверное уже знаете это, но я обобщу это для новичков. Запустите bundle installдля установки пакетов, необходимых для вашего проекта. Что если вы только что запустили git pull и там появились новые джемы? bundle install. Если вы только что добавили новые джемы или поменяли версии джемов в Gemfile? bundle install. Казалось бы более логичным будет запустить bundle update, но это не только установит джемы — оно также попробует обновить каждый джем в вашем пакете. Обычно это означает катастрофу, если, конечно, вы на самом деле это планировали.
Команду update следует использовать тогда, когда ваши используемые джемы обновились, и вы хотите, чтобы ваш пакет имел самую новую версию, которую позволит запустить ваш Gemfile. Запустите bundle outdated, чтобы распечатать список джемов, которые можно обновить. Если вы хотите обновить определённый джем, запустите bundle update GEM или bundle update, чтобы обновить всё. После обновления проследите за тем, чтобы пройти все тесты прежде чем коммитить ваш новый Gemfile.lock!
Show и open
Большинство знают о bundle show, который распечатывает полный путь к местонахождению установки джема (наверное, потому что эта команда запускается в случае успешной установки). Однако намного полезнее является команда bundle open, которая сразу откроет джем в вашем редакторе. Вот минималистичное демо:
Это всё, что вам нужно для того, чтобы открыть rack в вашем редакторе. Возможность открывать джемы без необходимости их искать может быть замечательным способом отладки. Это позволяет вставлять операторы для печати или отладки в считанные секунды. Если вы меняете свои джемы, не забудьте после этого их ресетнуть! В будущем для этого будет создана pristine команда, но пока что запускайте bundle exec gem pristine чтобы восстановить джемы, которые вы редактировали.
Поиск
Независимо от того, используете ли вы grep, ack или ag, стало очень просто настроить shell функцию, которая позволит вам производить поиск по пакету с помощью всего пары символов. Вот мои:
С этой функцией искать стало ещё проще и быстрее:
Binstubs
Одна из самых надоедающих вещей при использовании бандлера — это то, что вы (наверное) должны запускать bundle exec whatever каждый раз, когда хотите запустить любую команду. Самым простым способом обойти это является установка Bundler binstubs. Запустив bundle binstubs GEM, вы можете генерировать стабы (stubs) в папке bin/. Эти стабы будут подгружать ваш пакет и правильную версию джема, прежде чем запустить команду. Вот пример настройки binstub для rspec.
Используйте binstubs для часто запускаемых команд или для команд, которые вы, возможно, будете запускать через cronjob. Учитывая, что binstubs не должны подгружать много кода, они будут работать очень быстро. Rails 4 приспособил binstubs и выйдет с bin/rails и bin/rake. Они будут настроены, чтобы всегда запускаться для конкретного приложения.
Создание Gemfile
Я видел множество жалоб, что это очень неудобно каждый раз набирать source ‘https://rubygems.org/’ создавая новый Gemfile. К счастью, бандлер будет это делать за вас! Когда вы начинаете новый проект, вы можете создать новый Gemfile, используя Rubygems.org как источник, запустив лишь одну команду:
Теперь вы готовы добавлять джемы и устанавливать в своё удовольствие!
Локальные Git джемы
Многие спрашивали, как можно использовать бандлер для того, чтобы изменять и коммитить в джем в своём Gemfile. Благодаря усилиям José Valim, бандлер 1.2 позволяет делать это крайне элегантно. С помощью одной настройки вы можете загрузить свой собственный git клон в разработку, но при развёртывании в производство будет проверено, каким последним коммитом вы пользовались.
Вот как настроить локальную git копию rack:
После того, как всё настроено, вы можете как изменять код, который ваше приложение будет использовать, так и коммитить в тот репозиторий так часто, как вам захочется.
Версии Ruby
Еще одна особенность бандлера 1.2 — запросы версии руби. Если вы знаете, что ваше приложение работает только с одной версией руби, вы можете запросить эту версию. Просто добавьте одну строку в свой Gemfile, указывая номер версии как string.
Теперь бандлер вызовет исключение каждый раз, когда вы попытаетесь запустить ваше приложение на другой версии руби. Вам не нужно больше беспокоиться о том, что вы случайно будете использовать неверную версию при разработке!
Схема зависимости
Бандлер использует Gemfile, чтобы создать так называемую схему зависимостей, где показано множество джемов и их зависимости друг от друга. Иногда это очень интересно и удобно видеть графическую схему зависимостей, и это то, что делает команда bundle viz. Вам потребуется установить джемы GraphViz и ruby-graphviz.
После этого вы получите красивый обзор ваших зависимостей. Вот схема Gemfile, который содержит только один Rails джем.
IRB в вашем пакете
Перед большим финалом у меня есть для вас последний совет: консоль команд. Запустив bundle console у вас не просто откроется IRB prompt, но также загрузятся весь пакет и все джемы. Если вы хотите поэкспериментировать с используемыми джемами, но у вас нету Rails джема для вызова Rails консоли, это является отличной альтернативой.
Создание нового джема
Ну и, наконец, то, что является самым полезным в бандлере после всех установок. Учитывая, что бандлер создан для управления джемами, команда бандлера очень мотивирована, чтобы сделать управление и создание джемов крайне простым. Вы можете создать папку с основой своего джема, просто запустив bundle gem NAME. Получится папка с gemspec, readme и lib файлами, куда вы можете поместить свой код. Когда вы добавили код, вы можете установить этот джем в свою систему для проверки, запустив rake install. Когда вы довольны своим джемом и хотите поделиться с остальными, поместить новую версию джема в rubygems.org можно, запустив rake release. Как побочный положительный эффект джемы, созданные таким образом, можно использовать как гит джемы. Это значит, что вы (и все остальные, использующие этот джем) можете копировать, редактировать и собирать любой коммит.
Подведём итоги
Теперь, когда вы знаете столько полезных вещей о бандлере, я предлагаю вам это протестировать. Используйте поиск, создавайте джемы!
Насколько я могу судить, бандлер больше всего полезен тем, что он упрощает процесс совместного сотрудничества и использования кода, что делает Руби лучше для всех.
Заметка: друг Engine Yard, André Arko, член команды ядра бандлера, написал для нас сию замечательную статью. Не забудьте заглянуть и на его сайт.
Bundler — менеджер для управления gem’ами
Что такое Bundler?
Установка
Устанавливаем эту утилиту как любой другой gem:
gem install bundler
Для Rails 3.0 ничего больше делать не нужно, потому как он используется по умолчанию. А для Rails.2.3.x нужно выполнить следующие шаги. C начала добавить ниже приведенный код в boot.rb перед Rails.boot!:
class Rails::Boot
def run
load_initializer
extend_environment
Rails::Initializer.run(:set_load_path)
end
def extend_environment
Rails::Initializer.class_eval do
old_load = instance_method(:load_environment)
define_method(:load_environment) do
Bundler.require :default, Rails.env
old_load.bind(self).call
end
end
end
end
Далее создать файл preinitializer.rb в директории config/initializers с содержимым:
begin
# Require the preresolved locked set of gems.
require File.expand_path(‘../../.bundle/environment’, __FILE__)
rescue LoadError
# Fallback on doing the resolve at runtime.
require «rubygems»
require «bundler»
Bundler.setup
end
Конфигурирование
После создании нового Rails приложения в версии 3.0 в корне проекта уже существует файл Gemfile, который является конфигом для Bundler’а. Для версий Rails 2.3.x его нужно создать самому. Для этого нужно перейти в директорию проекта и выполнить команду:
В этом файле задаются все необходимые зависимости gem’ов. Рассмотрим какие именно возможности предоставляет данный конфиг файл.
Сперва задается ресурс откуда по умолчанию будут устанавливаться gem’ы:
Как уже многие знают ресурс gemcutter.org становится неким стандартом для хранения gem’ов, поэтому при создании конфига именно этот ресурс будет установлен по умолчанию. Но вы легко можете его заменить допустим на gems.github.com или добавить столько ресурсов сколько вам нужно:
source ‘http://gemcutter.org’
source ‘http://gems.github.com’
source ‘http://gems.rubyforge.org’
Далее уже идет список gem’ом которые нужны для работы приложения:
gem ‘will_paginate’
gem ‘oauth’
gem ‘money’
Здесь нужно отметить, что gem’ы можно объединять в группы и далее устанавливать только определенные группы:
group :development do
gem ‘rspec’
gem ‘populator’
gem ‘faker’
end
group :production do
gem ‘memcache-client’
end
Доступна и другая форма объединения gem’ов в группы:
gem ‘rspec’, :group => ‘development’
gem ‘populator’, :group => ‘development’
gem ‘memcache-client’, :group => ‘production’
По умолчанию все gem’ы включаются в группу default.
Если нужна именно конкретная версия gem’а то можно задать ее номер:
gem «rack», «1.0.1»
gem «rails», «>=2.3.2»
Есть возможность задать имя файла который будет подключен во время подключения библиотеки Bundler’ом. По умолчанию это имя gem’а поэтому в большинстве случаев ничего задавать не нужно. Опция которая позволяет задать имя файла для подключения называется require, используется она следующим способом:
gem ‘gchartrb’, :require => ‘google_chart’
В случае если нужно указать git репозитория для скачивания gem’а то нужно использовать опцию git:
gem ‘will_paginate’, :git => ‘git://github.com/mislav/will_paginate.git’
Использование
Как тока задали все нужные gem’ы, нужно выполнить команду:
Эта команда решит все зависимости и установит недостающие gem’ы. При этом если выполнить:
То вы там не увидите gem’ы которые были установлены с помощью bundler’а. Все установленные gem’ы находится в директории
/.bundler. Откуда он их и будет подключать.
Посмотреть список установленных gem’ов можно с помощью команды:
Если нужный gem уже установлен в системе, то для него будет создана ссылка. После каждого изменения файла Gemfile, нужно выполнить команду install. Папка
/.bundler не является обязательной, если вы хотите установить gem’ы в другую папку, это легко сделать:
Если помните, то в конфиг файле есть возможность включать все gem’ы в группы, так вот при установки можно указать какие группы gem’ов не устанавливать:
bundle install —without test
Допустим зачем устанавливать gem’ы на production server который нужны только для тестирования.
Если gem имеет исполняемые файлы, то их можно запускать след образом:
bundle exec cassandra_helper cassandra
Как только вы закончили разработку приложения, нужно заблокировать изменение Gemfile:
После выполнения данной команды создастся файл Gemfile.lock, который будет содержать все зависимости на основе установленых gem’ов у вас на компьютере. Это делается для того чтоб зафиксировать версии gem’ов при которых приложение работает корректно. Данный файл будет иметь следующий вид:
—
dependencies:
faker:
group:
— :development
version: «>= 0»
memcache-client:
group:
— :test
version: «>= 0»
sqlite3-ruby:
group:
— :default
version: «>= 0»
oauth:
group:
— :default
version: «>= 0»
specs:
— stomp:
version: 1.1.4
— populator:
version: 0.2.5
— json:
version: 1.2.0
— thrift:
version: 0.2.0
— thrift_client:
version: 0.3.3
— rspec:
version: 1.3.0
— ruby-hmac:
version: 0.4.0
— oauth:
version: 0.3.6
hash: 0ac3c8666943a1e2294be2851316d83791479451
sources:
— Rubygems:
uri: gemcutter.org
В bundler’е предусмотрена возможность упаковки gem’ов:
После выполнения данной команды в директории vendor/cache будут сохранены все нужные gem’ы, впоследствии чего установка gem’ов будет происходить именно с этой директории. Эта опция будет полезна только для тех у кого нет возможности на production server устанавливать gem’ы с публичных репозиториев.
Вот и все, что я хотел вам рассказать об этой удобной утилите. Попробуйте поработать с ней хотя бы час и я думаю, она вам понравится.
Install bundle что это
Description
Options
Creates a directory (defaults to
/bin ) and places any executables from the gem there. These executables run in Bundler’s context. If used, you might add this directory to your environment’s PATH variable. For instance, if the rails gem comes with a rails executable, this flag will create a bin/rails executable that ensures that all referred dependencies will be resolved using the bundled gems.
This option is deprecated in favor of the clean setting.
In deployment mode, Bundler will ‘roll-out’ the bundle for production or CI use. Please check carefully if you want to have this option enabled in your development environment.
This option is deprecated in favor of the deployment setting.
Force download every gem, even if the required versions are already available locally.
Do not allow the Gemfile.lock to be updated after this install. Exits non-zero if there are going to be changes to the Gemfile.lock.
This option is deprecated in favor of the frozen setting.
Bundler will not call Rubygems’ API endpoint (default) but download and cache a (currently big) index file of all gems. Performance can be improved for large bundles that seldom change by enabling this option.
The location of the Gemfile (5) which Bundler should use. This defaults to a Gemfile (5) in the current working directory. In general, Bundler will assume that the location of the Gemfile (5) is also the project’s root and will try to find Gemfile.lock and vendor/cache relative to this location.
Do not update the cache in vendor/cache with the newly bundled gems. This does not remove any gems in the cache but keeps the newly bundled gems from being cached during the install.
Don’t remove stale gems from the cache when the installation finishes.
This option is deprecated in favor of the no_prune setting.
This option is deprecated in favor of the path setting.
Retry failed network or git requests for number times.
This option is deprecated in favor of the shebang setting.
This option is deprecated in favor of the system setting.
This option is deprecated in favor of the with setting.
This option is deprecated in favor of the without setting.
Deployment Mode
A Gemfile.lock is required.
To ensure that the same versions of the gems you developed with and tested with are also used in deployments, a Gemfile.lock is required.
This is mainly to ensure that you remember to check your Gemfile.lock into version control.
The Gemfile.lock must be up to date
In development, you can modify your Gemfile (5) and re-run bundle install to conservatively update your Gemfile.lock snapshot.
Gems are installed to vendor/bundle not your default system location
In development, it’s convenient to share the gems used in your application with other applications and other scripts that run on the system.
In deployment, isolation is a more important default. In addition, the user deploying the application may not have permission to install gems to the system, or the web server may not have permission to read them.
Sudo Usage
In some cases, that location may not be writable by your Unix user. In that case, Bundler will stage everything in a temporary directory, then ask you for your sudo password in order to copy the gems into their system location.
From your perspective, this is identical to installing the gems directly into the system.
As a result, you should run bundle install as the current user, and Bundler will ask for your password if it is needed to put the gems into their final location.
Installing Groups
This is so that installing a different set of groups on another machine (such as a production server) will not change the gems and versions that you have already developed and tested against.
Bundler offers a rock-solid guarantee that the third-party code you are running in development and testing is also the third-party code you are running in production. You can choose to exclude some of that code in different environments, but you will never be caught flat-footed by different versions of third-party code being used in different environments.
For a simple illustration, consider the following Gemfile (5) :
In this case, sinatra depends on any version of Rack ( >= 1.0 ), while rack-perftools-profiler depends on 1.x (
This should not cause any problems in practice, because we do not attempt to install the gems in the excluded groups, and only evaluate as part of the dependency resolution process.
The Gemfile.lock
Because of the way dependency resolution works, even a seemingly small change (for instance, an update to a point-release of a dependency of a gem in your Gemfile (5) ) can result in radically different gems being needed to satisfy all dependencies.
As a result, you SHOULD check your Gemfile.lock into version control, in both applications and gems. If you do not, every machine that checks out your repository (including your production server) will resolve all dependencies again, which will result in different versions of third-party code being used if any of the gems in the Gemfile (5) or any of their dependencies have been updated.
Conservative Updating
Let’s take a look at an example. Here’s your original Gemfile (5) :
Next, you modify your Gemfile (5) to:
The actionpack 3.0.0.rc gem has a number of new dependencies, and updates the activesupport dependency to = 3.0.0.rc and the rack dependency to
> 1.1.0 not currently being used to satisfy another dependency
Управляем версиями с помощью Bundler
Недавно вышло обновление rake с версии 0.8.7 до версии 0.9.0, которое наделало много шума в сообществе и в очередной раз выявило проблему управления версиями. Мне бы хотелось прояснить ситуацию и снова проговорить основные моменты, которые я уже упоминал во времена релиза Bundler 1.0. Вначале я расскажу о простых правилах работы, а затем слегка углублюсь в детали.
Простое управление версиями
Исполняемые файлы
Когда вы устанавливаете гем, Rubygems создает обертки для всех исполняемых файлов, идущих в комплекте с гемом. При запуске обертки, запускается Rubygems, который подключает сам гем с помощью стандартного механизма активации. Rubygems запустит самую свежую версию гема, установленную в системе, даже если в Gemfile.lock указана другая версия. Кроме того, будут активированы последние (совместимые) версии всех зависимостей гема, даже если в Gemfile.lock указаны другие версии.
Это означает, что запуск исполняемых файлов как простых команд просто минует Bundler и все залоченые им зависимости. Иногда это не проблема, поскольку у разработчиков скорее всего стоят как раз нужные версии всех гемов. Долгое время Rake был отличным примером такого гема с «правильной» версией, поскольку большинство Gemfile.lock были залочены на версию 0.8.7, которая являлась последней доступной версией и была установлена у всех.
В результате образовалось заблуждение, что прямой запуск исполняемых файлов совместим с Bundler и использует его для разрешения зависимостей. В случае проблем обычно рекомендовалось использовать гемсеты из RVM, поскольку гемсет, собранный из Gemfile.lock, по сути подразумевал, что все исполняемые файлы окружения работали с нужными версиями зависимостей.
Нет никаких оснований полагать, что набирая в консоле rake foo вы запускаете код песочнице Bundler, поскольку на самом деле он никак не задействован и нигде не запускается. Bundler должен активироваться в самом начале загрузки и иметь возможность подменить загрузчик подсунув ему нужные версии гемов прописанные в Gemfile.lock. Запуская исполняемые файлы напрямую вы исполняете руби-код до того, как Bundler мог бы вмешаться в процесс подключения зависимостей. В итоге подключается совсем не тот код, на который вы расчитываете. Как только это произошло, все становится весьма непредсказуемым.
Директория bin создает «переносимые» обертки для запускаемых файлов, поэтому ее смело можно добавлять в репозиторий.
Команда rails
Содержимое файла boot.rb в свою очередь весьма нетривиально:
Install bundle что это
—clean : Run bundle clean automatically after install
—deployment : Install using defaults tuned for deployment and CI environments
—frozen : Do not allow the Gemfile.lock to be updated after this install
—full-index : Use the rubygems modern index instead of the API endpoint
—gemfile : Use the specified gemfile instead of Gemfile
—jobs : Install gems using parallel workers.
—local : Do not attempt to fetch gems remotely and use the gem cache instead
—no-cache : Don’t update the existing gem cache.
—no-prune : Don’t remove stale gems from the cache.
—quiet : Only output warnings and errors.
—retry : Retry network and git requests that have failed.
—shebang : Specify a different shebang executable name than the default (usually ‘ruby’)
—standalone : Make a bundle that can work without the Bundler runtime
—trust-policy : Sets level of security when dealing with signed gems. Accepts `LowSecurity`, `MediumSecurity` and `HighSecurity` as values.
—without : Exclude gems that are part of the specified named group.
Gems will be installed to your default system location for gems. If your system gems are stored in a root-owned location (such as in Mac OSX), bundle will ask for your root password to install them there.
While installing gems, Bundler will check vendor/cache and then your system’s gems. If a gem isn’t cached or installed, Bundler will try to install it from the sources you have declared in your Gemfile.
