Могу ли я отредактировать установленный гем с помощью 'gem install' или из моего гемфайла? - PullRequest
17 голосов
/ 31 декабря 2011

На моем сервере (или ноутбуке в этом отношении) всякий раз, когда я устанавливаю гем, используя:

gem install mygemname

или в моем gemfile:

gem 'mygemname'

Он будет установлен на компьютере в какую-либо папку на моем компьютере.

Могу ли я зайти в эту папку и отредактировать файл, если я хочу сказать добавить запись в журнал и т. Д .?

Если это невозможно, я помню, что читал, что вы можете установить исходный код gem в вашем приложении rails 3 в папке vendor. Как установить его локально, чтобы я мог отредактировать его и добавить к нему логи (чтобы узнать, как это работает и т. Д.)

Ответы [ 4 ]

61 голосов
/ 01 января 2012

Можете ли вы?

Да

Если вы?

Абсолютно нет.

Почему?

  • Изменениеисточник драгоценных камней делает очень сложным обновление до новых версий гема
  • Гораздо сложнее отлаживать проблему
  • Это вызовет ОГРОМНУЮ головную боль
  • Это делает еготрудно работать в среде совместной работы (есть ли у каждого разработчика правильный взломанный драгоценный камень?)
  • Это вызывает такие вопросы (например, где я должен взломать драгоценный камень?)

Решения

Есть несколько способов решить эту проблему:

Отправить исправление

Если вы считаете, что это «изменение» принесет пользу всему сообществу,найдите исходный код (скорее всего, на github ), разветвитесь, примените патч, напишите тесты и отправьте pull-запрос.Если разработчик согласится с тем, что ваш патч жизнеспособен, он будет объединен с проектом и выпущен со следующей версией гема.

Преимущества
  • Вы помогаете сообществу
  • У вас есть локальная копия драгоценного камня (так как вы его разветвили) на компьютере разработчика
Недостатки
  • Вам нужно подождать, пока разработчик примет ваш патч
  • Это может занять довольно много времени

Re-Gem

Если вы не думаете, что это принесет пользу всему сообществу, но вы все еще хотите позволить другим разработчикам систематически использовать этот драгоценный камень, раскошелиться на существующий драгоценный камень, применить свойисправьте, переименуйте драгоценный камень и опубликуйте.в этом случае хорошей практикой является добавление префикса к вашему оригинальному самоцвету.Например, если камень был назван foo, вы бы назвали свой камень foo-my-company.Теперь вы можете выбрать этот драгоценный камень с открытым исходным кодом (push to rubygems) или отправить его на частный сервер разработки в вашей организации. Вы по-прежнему должны указывать автора оригинального драгоценного камня в своем обновлении!

Преимущества
  • Не нужно ждать разработчика
  • Центральная база кода
  • Легко используется
Недостатки
  • Сложно обновить с оригинального гема
  • Может быть громоздким в обслуживании

Local Lib (monkey-patch)

Вы можете создать monkey-patch внутри вашего приложения и переопределить любые методы или свойства, которые не соответствуют вашей текущей среде.

Преимущества
  • Быстро и просто
  • Легко делится (через git - просто включите файл патча в репо)
Недостатки
  • Обновление драгоценного камня затруднено
  • Другим разработчикам не ясно, что вы модифицируете ядро ​​драгоценного камня
  • Труднее отладить (это ошибка с драгоценным камнем или вашпатч?)

Форк и источник

Это мой рекомендуемый вариант.Почему я поставил это в последнюю очередь - другие встречаются чаще.В этом методе вы разветвляете гем из его исходного репозитория (возможно, на github), а затем получаете свой камень из вашего git репо.Например, скажем, драгоценный камень был назван foo, вы бы разветвлялись от foo до username/foo на github.Применяйте свои патчи, изменения, что угодно.Затем в вашем Gemfile:

gem 'gem_name', :git => 'git://github.com/username/foo'

Это установит и скомпилирует гем из источника в вашем репо при каждом запуске команды bundle.Вы также можете указать конкретный тег и ветку (рекомендуется для стабильности).

Преимущества
  • Вы можете легко обновить апстрим (у вас есть форк - вытащить из апстрима, объединить, у вас есть все изменения)
  • Контроль версий прост (используйте теги и ветки для разных версий)
  • Каждый имеет доступ к одному и тому же источнику самоцветов
  • Простота управления обновлениями
Недостатки
  • Ваш "пользовательский" код является общедоступным (хотя для решения этой проблемы вы можете использовать собственный сервер git вместо github)

Заключение

У каждого метода есть свои преимущества и недостатки (которые я старался перечислить как можно лучше).В любом случае, предложенный вами метод является , а не рекомендуемым методом для решения этой проблемы.

Если у читателей есть комментарии о других преимуществах / недостатках, перечислите их, и я добавлю их в свой ответ.

3 голосов
/ 31 декабря 2011

Совет Дэйва Ньютона - мудрость, и вы должны принять ее, но нет ничего плохого в том, чтобы взглянуть на нее, чтобы чему-то научиться.Запуск gem env покажет вам, где установлены ваши драгоценные камни;каталог lib - это то место, где вы стремитесь найти суть кода.

3 голосов
/ 31 декабря 2011

Конечно, это просто код.

Должен ли вам?Не в общем, так как его можно переустанавливать, обновлять и т. Д.

Поскольку вы можете заново открывать классы IMO, безопаснее обезьяна, исправление, расширение и расширение и т. Д. Это не всегда так практичнокак прямое изменение, конечно.

Для образовательных целей (когда не имеет значения, потеряны ли модификации), это хорошо и имеет больше смысла, чем дублирование всего.Ведение журнала AOP-ish часто выполнимо без изменения исходного источника.Иногда клонирование репо и его использование, особенно на исследовательских этапах, является более чистым.

0 голосов
/ 31 декабря 2011

У нас было это обсуждение на работе, и я не одобряю эту практику.

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

Вы можете заморозить свою версию, сделав ее доступной только для чтения, или использовать упаковщик или скопировать весь дистрибутив Ruby, но в каждом из них вы идете против течения.

Вместо этого я рекомендую:

  1. Напишите патч для рассматриваемого метода в одном из ваших собственных файлов.Я скопировал определение метода в отдельный файл в каталоге lib моего приложения и внес в него изменения, затем required в последнюю очередь, что позволило исправить метод, не нарушая обычного использования Gem.
  2. Отправьте свое изменение сопровождающему gem в виде патча вместе с указанием причины, по которой вам нужно это изменение.
  3. Удалите файл и require, если / когда изменение будет принято.

Раньше я работал в крупной корпорации, которая решила, что было бы неплохо сделать патч для одного из исходных файлов в их почтовой системе.Программное обеспечение не было чем-то, что они писали сами, поэтому со временем они все больше и больше времени приходилось вносить свои «особые» изменения в программное обеспечение по мере того, как производитель наращивал продукт.В конце концов, потребовались месяцы, чтобы внести изменения и сделать программное обеспечение хрупким, что не очень хорошо для чего-то, что является основным бизнес-сервисом.Способность Руби переопределить метод спасла бы им неисчислимые доллары и месяцы работы.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...