Используйте бандлер вместо практики rvm gemset per project

[@nuclear]

Радует количество статей по Руби/RoR. Спасибо!

[@icesik]

Всё правильно, но ещё лучше делать bundle pack для упаковки джемов прям в проект. При деплое bundle install --local не будет лезть на rubygems.org за джемами. Единственное что с джемами которые подключены через :git это не работает. Их наверно просто надо вендорить.

[@akzhan]

Достаточно форкать их в локальный Gitorious/Gitosis ;)

[@azakharov]

Это не слишком сложно? После того как мы все наши репы перевели на гитхаб. я вспоминаю об этих двух словах с ужасом.

[@akzhan]

Это внешняя зависимость от GitHub, что для компании, занимающейся развертыванием серверов очень часто, бывает неприемлемо.

[@azakharov]

Нам слава богу это пока не грозит =)

[@azakharov]

Bundle pack выполняют несколько другую функцию и нужен именно для деплоя.

[@azakharov]

Точно не уверен. В текущем проекте гитовских гемов у меня нет. Но помоему они должны уже попадать в vendor/cache судя по документации.

[@VolCh]

>Также не забудьте добавить ее в гитигнор.

Зачем? По-моему логично, что если пакет per project, то он должен быть под контролем версий.

[@azakharov]

Под контролем версий должен быть гем файл в котором описан список гемов. Разве нет? Любой репозиторий распухнет от гемов. Ну или я вас неправильно понял.

[@VolCh]

Если там только список, без номеров версий, то, имхо, этого маловато.

[@azakharov]

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

[@Bregor]

Загляните в Gemfile.lock.

[@opti]

А мы вот как-то наоборот с развитием ror стали выкидывать из папок проекта все лишнее, начиная с самих rails, потом плагины, гемы, потом появился bundler и жизнь стала совсем сказкой. Не хочется возвращаться…

Кроме того, на мой скромный взгляд, при необходимости писать продукт под разные версии ruby, 1.8.7 и 1.9.2 к примеру, под которые требуются еще и разные версии конкретных гемов — гемсеты рвм'а удобнее. И упаси Матц поддерживать разные версии rubygems с таким подходом :)

К слову, смысла складывать все в проект, а потом добавлять путь в гитигнор действительно нету. Бандлер будет замечательно работать и при дефолтном месте установки гемов. Главное, чтобы в вашем Gemfile были правильно указаны нужные вам версии гемов. Устанавливать же несколько разных версий гемов можно было изначально.

А как поступать с компилируемыми гемами? Они не сложатся полностью в ваш проект.

Имхо, и бандлер и rvm очень классные штуки, но я бы не назвал их взаимозаменяемыми.

[@azakharov]

Лично меня просто бесило создавать новые гемсеты. Это не напрягает на больших проектах. А когда ты сидишь и экспереметируешь создавая микро проекты или либы, то необходимость создать гемсет становится чудовищным гемором.

>> А как поступать с компилируемыми гемами?
Вот в текущем проекте у меня есть компилируемые гемы типа bson_ext. Проблем никаких нет. В глобальном гемсете только бандлер и рейк.

[@ptzn]

А в чем сложность создавания гемсетов? Особенно если это дело можно автоматизировать, добавляя в проект файл .rvmrc. Да, кстати, для микропроектов и либ можно завести специальный гемсет.

[@azakharov]

Мне лень писать команду rvm create gemset. Я хочу сделать git pull, bundle update и все.

Тем более после удаления проектов их гемесеты тоже надо удалять.

Я понимаю, что все можно… мы так и делали. Суть моего поста в том, что можно делать проще.

[@Bonch]

Сделайте темплейт, который будет все сам создавать (если используете rails 3).

[@ptzn]

Тут, как обычо, на вкус и цвет :) Мне, например, более раздражает каждый раз звать bundle exec, хотя и это решается через алиасы в шелле.

[@rwz]

Не очень понятно, нафига бандлиться в /vendor/bundle, если его все равно не добавлять в репу.

Я тупо ставлю все гемы глобально. В итоге, намного меньше дублирования происходит. Тот же therubyracer не приходится собирать с нуля для каждого отдельного проекта, например. А Gemfile.lock + bundler exec как раз гарантирует, что я всегда имею дело с правильными версиями чего бы то ни было.

[@azakharov]

Ну бандлить в папку хорошо по той же причине зачем делают гемсет на проект. Согласен, что в большинстве случаев глобальные гемы себя нормально могут вести, но когда что то пойдет не так… можно кучу времени сидеть с красными глазами и рвать у себя волосы на лобке =)

[@rwz]

Кстати, теги на хабре разделяются запятой. А у вас получился один тег ruby rvm bundler.

[@azakharov]

Точняк =)

[@atipugin]

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

[@diner]

Vendor Everything
ryan.mcgeary.org/2011/02/09/vendor-everything-still-applies/

[@azakharov]

пост немного устарел

корректнее бандлить именно в vendor/bundle (который фигурирует в документации). данный путь уже находится в rails гитигноре на гитхабе github.com/github/gitignore/blob/master/Rails.gitignore

[@Iskin]

Лучше сохранять не в vendor/bundle, а в .bundle. Последняя сразу находится в .gitirgnore

[@azakharov]

Я ориентировался на это gembundler.com/bundle_install.html

[@azakharov]

Install your dependencies, even gems that are already installed to your system gems, to a location other than your system's gem repository. In this case, install them to vendor/bundle.

[@azakharov]

vendor/bundle тоже есть в рекомендуемом gitignore github.com/github/gitignore/blob/master/Rails.gitignore

[@ring0]

Мне лично удобно использовать rvm gemsets, так как не надо постоянно bundle exec набирать.

[@merkuriy]

Если «bundle exec» кажется длинноватым, можно сделать так что бы в проекте была папка /bin с с исполняемыми файлами привязанными к Gemfile.lock. Для это выполните:
bundle install --binstubs

И можете теперь использовать более короткий «bin/»