rubyruby-on-railsrubyrake

У меня есть задача Rails: мне использовать скрипт / бегун или грабли?

просмотры: 33.5K

Для специальных задач Rails у нас есть несколько альтернатив реализации, главными из которых могут быть:

script/runner some_useful_thing

а также:

rake some:other_useful_thing

Какой вариант мне предпочесть? Если есть явный фаворит, то когда, если вообще, стоит подумать об использовании другого? Если нет, то почему вы предполагаете, что он все еще присутствует в структуре без предупреждений об устаревании?

Источник

Ответов (8)

Решение

Разница между ними в том, что script/runner Rails загружается, тогда как задача Rake не загружается, если вы не укажете ей, сделав задачу зависимой от :environment, например:

task :some_useful_task => :environment do
  # do some useful task
end

Поскольку загрузка Rails стоит дорого, возможно, стоит ее пропустить, если вы можете этого избежать.

В остальном они примерно эквивалентны. Я использую и то, и другое, но в последнее время script/runner чаще использую выполнение скрипта по отдельности.

Источник

Передача параметров в задачу с граблями - это, мягко говоря, головная боль. Вам нужно либо прибегнуть к переменным среды, либо к очень хакерской системе параметров, которая не является интуитивно понятной и имеет множество предостережений.

Если ваша задача должна изящно обрабатывать аргументы командной строки, то лучше всего написать сценарий.

Люк Франкл упоминает скрипт / раннер, загружающий Rails. Это правда. Но если вы не хотите загружать рельсы, просто запустите скрипт без скрипта / бегуна. Таким образом, единственное реальное различие между скриптами и граблями - это их эстетика. Выбирайте то, что вам нравится.

Я использую грабли для небольших задач (одна или две строки). Все, что посложнее, помещается в каталог script /. Я нарушу это правило, если думаю, что другие разработчики будут ожидать, что код будет жить в одном месте, а не в другом.

Источник

Для одноразовых команд script / runner может быть в порядке. Если что-то повторяется, задача с граблями проще в долгосрочной перспективе, и у нее есть сводка, если вы забудете, что она делает.

Источник

У меня сложилось впечатление, что скрипт / раннер предназначен в первую очередь для периодических задач. Например, задание cron, которое запускается:

SomeClass.update_from_web('http://www.sourcefordata.gov/')
Источник

Единственное, что я сделал, это просто написал обычные скрипты Ruby и поместил их в script/maintenance каталог.

Все, что вам нужно сделать, чтобы загрузить рельсы и получить доступ ко всем вашим моделям и т. Д., Помещается require '../../config/environment.rb' в верхнюю часть вашего файла, и вы уезжаете.

Источник

FWIW, похоже, есть некоторый отход от использования script runner в пользу rake:

Обновление (25.04.2009): я рекомендую использовать задачи с граблями, а не сценарий / бегун для повторяющихся задач.

Кроме того, согласно этому сообщению, вы можете использовать грабли для повторяющихся задач:

Если бы я хотел, чтобы это выполнялось каждую ночь в моей производственной базе данных в полночь, я мог бы написать задание cron, которое выглядит примерно так:

0 0 * * * cd / var / www / apps / rails_app / && / usr / local / bin / rake RAILS_ENV = производственные утилиты: send_expire_soon_emails

Источник

Исправлено на основании комментария 2 вниз. Отдай им карму!

FWIW - Rails 3.0+ изменяет способ инициализации системы Rails в автономном скрипте.

require File.dirname(__FILE__) + '/config/environment'

Как упоминалось выше, вы также можете:

rails runner script/<script name>

Или поместите весь код в задачу Rake, но у меня много устаревшего кода из Rails 2; так что я не хотел сразу идти по этому пути.

У каждого есть свои преимущества и недостатки.

Источник

В Rails 3.0+ config/environment.rb требуется то config/application.rb, что требует config/boot.rb .

Итак, чтобы загрузить приложение в Rails 3, вам все равно нужно потребовать только environment.rb

Источник