Комментарии 32
Радует количество статей по Руби/RoR. Спасибо!
+9
Всё правильно, но ещё лучше делать bundle pack для упаковки джемов прям в проект. При деплое bundle install --local не будет лезть на rubygems.org за джемами. Единственное что с джемами которые подключены через :git это не работает. Их наверно просто надо вендорить.
+1
Достаточно форкать их в локальный Gitorious/Gitosis ;)
0
Bundle pack выполняют несколько другую функцию и нужен именно для деплоя.
0
Точно не уверен. В текущем проекте гитовских гемов у меня нет. Но помоему они должны уже попадать в vendor/cache судя по документации.
0
>Также не забудьте добавить ее в гитигнор.
Зачем? По-моему логично, что если пакет per project, то он должен быть под контролем версий.
Зачем? По-моему логично, что если пакет per project, то он должен быть под контролем версий.
0
А мы вот как-то наоборот с развитием ror стали выкидывать из папок проекта все лишнее, начиная с самих rails, потом плагины, гемы, потом появился bundler и жизнь стала совсем сказкой. Не хочется возвращаться…
Кроме того, на мой скромный взгляд, при необходимости писать продукт под разные версии ruby, 1.8.7 и 1.9.2 к примеру, под которые требуются еще и разные версии конкретных гемов — гемсеты рвм'а удобнее. И упаси Матц поддерживать разные версии rubygems с таким подходом :)
К слову, смысла складывать все в проект, а потом добавлять путь в гитигнор действительно нету. Бандлер будет замечательно работать и при дефолтном месте установки гемов. Главное, чтобы в вашем Gemfile были правильно указаны нужные вам версии гемов. Устанавливать же несколько разных версий гемов можно было изначально.
А как поступать с компилируемыми гемами? Они не сложатся полностью в ваш проект.
Имхо, и бандлер и rvm очень классные штуки, но я бы не назвал их взаимозаменяемыми.
Кроме того, на мой скромный взгляд, при необходимости писать продукт под разные версии ruby, 1.8.7 и 1.9.2 к примеру, под которые требуются еще и разные версии конкретных гемов — гемсеты рвм'а удобнее. И упаси Матц поддерживать разные версии rubygems с таким подходом :)
К слову, смысла складывать все в проект, а потом добавлять путь в гитигнор действительно нету. Бандлер будет замечательно работать и при дефолтном месте установки гемов. Главное, чтобы в вашем Gemfile были правильно указаны нужные вам версии гемов. Устанавливать же несколько разных версий гемов можно было изначально.
А как поступать с компилируемыми гемами? Они не сложатся полностью в ваш проект.
Имхо, и бандлер и rvm очень классные штуки, но я бы не назвал их взаимозаменяемыми.
+6
Лично меня просто бесило создавать новые гемсеты. Это не напрягает на больших проектах. А когда ты сидишь и экспереметируешь создавая микро проекты или либы, то необходимость создать гемсет становится чудовищным гемором.
>> А как поступать с компилируемыми гемами?
Вот в текущем проекте у меня есть компилируемые гемы типа bson_ext. Проблем никаких нет. В глобальном гемсете только бандлер и рейк.
>> А как поступать с компилируемыми гемами?
Вот в текущем проекте у меня есть компилируемые гемы типа bson_ext. Проблем никаких нет. В глобальном гемсете только бандлер и рейк.
0
А в чем сложность создавания гемсетов? Особенно если это дело можно автоматизировать, добавляя в проект файл .rvmrc. Да, кстати, для микропроектов и либ можно завести специальный гемсет.
0
Не очень понятно, нафига бандлиться в
Я тупо ставлю все гемы глобально. В итоге, намного меньше дублирования происходит. Тот же therubyracer не приходится собирать с нуля для каждого отдельного проекта, например. А Gemfile.lock +
/vendor/bundle
, если его все равно не добавлять в репу.Я тупо ставлю все гемы глобально. В итоге, намного меньше дублирования происходит. Тот же therubyracer не приходится собирать с нуля для каждого отдельного проекта, например. А Gemfile.lock +
bundler exec
как раз гарантирует, что я всегда имею дело с правильными версиями чего бы то ни было.0
Кстати, теги на хабре разделяются запятой. А у вас получился один тег
ruby rvm bundler
.0
Использую гемсет только для предрелизных сборок рельс, в остальном само собой бандлер
0
Vendor Everything
ryan.mcgeary.org/2011/02/09/vendor-everything-still-applies/
ryan.mcgeary.org/2011/02/09/vendor-everything-still-applies/
-1
пост немного устарел
корректнее бандлить именно в vendor/bundle (который фигурирует в документации). данный путь уже находится в rails гитигноре на гитхабе github.com/github/gitignore/blob/master/Rails.gitignore
корректнее бандлить именно в vendor/bundle (который фигурирует в документации). данный путь уже находится в rails гитигноре на гитхабе github.com/github/gitignore/blob/master/Rails.gitignore
0
Лучше сохранять не в vendor/bundle, а в .bundle. Последняя сразу находится в .gitirgnore
0
Я ориентировался на это gembundler.com/bundle_install.html
0
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.
0
vendor/bundle тоже есть в рекомендуемом gitignore github.com/github/gitignore/blob/master/Rails.gitignore
0
Мне лично удобно использовать rvm gemsets, так как не надо постоянно bundle exec набирать.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Используйте бандлер вместо практики rvm gemset per project