Ответ 1

Можете ли вы?

Да

Должны ли вы?

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

Почему?

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

Решение

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

Отправить патч

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

• Вы помогаете сообществу
• У вас есть локальная копия драгоценного камня (так как вы его разветвляли) на вашей машине разработки.

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

Re-Gem

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

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

• Трудно обновить исходный камень
• Может быть громоздко поддерживать

Локальный Lib (обезьяна-патч)

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

• Быстрый и простой
• Легко разделяемый (через git - просто включите файл исправления в свое репо)

• Обновление драгоценного камня затруднено.
• Не понятно другим разработчикам, что вы модифицируете ядро ​​Gem
• Сложнее отлаживать (это ошибка с камнем или патчем?)

Вилка и источник

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

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

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

• Вы можете легко обновить восходящий поток (у вас есть fork-pull из восходящего потока, слияния, у вас есть все изменения)
• Управление версиями легко (используйте теги и ветки для различных версий)
• У каждого есть доступ к одному и тому же источнику драгоценных камней.
• Простота управления обновлениями

• Ваш "настраиваемый" код является общедоступным (хотя вы можете использовать собственный сервер git вместо github для решения этой проблемы)

Заключение

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

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

Ответ 2

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

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

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

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

Ответ 3

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

Ответ 4

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

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

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

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

• Напишите патч к рассматриваемому методу в одном из ваших собственных файлов. Я скопировал определение метода в отдельный файл в моем приложении lib, и сделал там изменение, затем required он последний, позволяя исправлять метод без нормального использования Gemvergem.
• Отправьте свое изменение в хранителя драгоценных камней в виде патча вместе с вашей причиной необходимости изменения.
• Удалите файл и require, если/когда изменение принято.

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