“I monkey patch from time to time.” | Hacker News Reader

“I monkey patch from time to time.”

medium.com

29 pointsMeyborg20 comments

Monkey patching is extremely useful in Ruby but it has to be done with great care. Not having monkey patching available in an OO codebase comes with a lot of headaches.

Small example: You're using a 3rd party library that happens to include layers of object inheritance. You notice a piece of functionality a couple of layers up that you need access to or actually requires correction, but wasn't exposed in a way that you can fix it. With monkey patching, you can add a couple of lines of code in your code base that corrects the library without any changes elsewhere. Then you add a test to monitor it to see if something ever changes.

Without monkey patching, you have to fork the entire 3rd party library, make the change, use your fork on your project, keep it up to date and hope the library owner eventually accepts your PR. OR use the code as is and rebuild the inheritance tree in your own code base everywhere it's impacted.

It's indispensable when this scenario comes up.

Yep, Ruby has two perfect examples of double-edged swords: monkey patching and 'method missing'. They are both absolutely priceless when leveraged "for good". When leveraged inappropriately however, they can bring the entire thing down. On balance, I love ruby for having the capability to do these things.

Yea, I always go to the WAT talk whenever I describe method_missing.

In the Python codebases I work on, I always create a monkey.py in the repo root. With a comment warning against adding to it, but occasionally it’s the lesser evil.

A long time ago, when Django was less mature we had a monkey patch to add a join condition to some of our queries. It obviously broke when we needed to upgrade to Django 2, but it did allow us to eek out a major performance boost without abandoning the ORM quest builder. One of my coworkers practically fell over laughing when he discovered the file.

Sounds like you should add some conditionals so that one can easily monkeypatch the monkeypatching. `if django_patch_enable: import xyz; xyz.foo = 1`

I patched a Python Paramiko method to log all data immediately when it came over the wire for an automation library that ran a lot of our automated testing. It's hard to overstate how helpful this was when data seem to be missing. Once we overflowed an internal Paramiko buffer because it wasn't documented and we overlooked this possibility. The logging was important to pinning down the problem. The monkey patching was complex and ugly but ultimately worth it.

Whenever monkey patching comes up, I always remember the time when a popular JS library forced an upcoming standard to change its name so as not to conflict with its monkey-patched addition: https://developer.chrome.com/blog/smooshgate/

That was an extension, usually the goal of monkey patching is to alter or replace the behaviour of an existing feature which is not exposed in a way which allows it (or you want to make sure nobody will use it wrong). So a monkey patch in the classic sense does not conflict with upstream updating their API.

And because you’re in control and the upstream has no idea you’re doing what you’re doing, breakage will fall on you anyway v

One of the standard solutions to "library we use isn't yet compatible with ___" is:

1. Monkey patch it to be compatible

2. Include in the monkey-patch initializer a version check, so the monkey-patch won't outlive the current version of the dependency

3. Submit a pull-request or open an issue upstream to resolve the compatibility issue.

This comes up _constantly_ during ruby version updates and when updating central libraries that many others depend on (like activesupport).

The other alternative is usually to fork the gem yourself and resolve the compatibility issues, and depend on your forked version - then you need to stay on top of updating and building your fork regularly. Multiply that by a dozen or so different cases, and it becomes clear that monkey-patching is in some cases _the right thing to do_, and not a "bad habit" at all.

> This comes up _constantly_ during ruby version updates and when updating central libraries that many others depend on (like activesupport).

I understand this was pretty common in the early days of Ruby, around 1.8.7, 1.9.3, 2.0, etc, along with Rails 2.x and earlier. I maintain a number of Rails apps, both at work and personal, and I've never had to do this or heard of anyone else doing it post roughly Rails 4.x and Ruby 2.2+.

Perhaps you use a smaller set of dependencies, wait a while before upgrading, or got lucky? It was necessary for us during the ruby 3.0 and 3.1 upgrades, and during the rails 7.0 upgrade.

In particular, the change during ruby 3.0 to the handling of keyword arguments vs final hash params broke a _lot_ of gems (like memoist and ruby-kafka's datadog integration), that wrap arbitrary methods, because when they wrap keyword-argument methods, they passed the arguments into the wrapped method as hash-args instead.

I expect that the longer you wait after a release to upgrade, the less it's an issue - the ecosystem takes time to catch up. We've been staying fairly on top of the upgrades.

Could be the time thing. Some of our apps at work have big-ish gem sets, but our ruby version upgrade cadence is much closer to update the version when the current one is about to go out of support for security updates than grab the new hotness within a week of it being released.

Oh yeah, that'll definitely do it. Our prior policy was to only adopt a version of rails when it's no longer the newest version of rails, and even that was enough to avoid most compatibility issues. We currently tend to adopt new versions of rails and ruby about a quarter after they are released (I wouldn't recommend "within a week" to any large project).

It's worth noting that the reason there aren't a ton of compatibility issues 9 months after those things are released is _because_ of shops that perform the upgrades, find the issues, and report or solve them before then. The later you choose to go in the cycle, the less you'll be impacted, and the less you will contribute.

No offense to the OP, as it is a well written article on a fairly common bad habit, but...

I gotta say I'm sick of advertisements masquerading as blog posts. It is like tech bro astro-turfing, and frankly insufferable to see the owner of a SaaS/package/product describe their own stuff as "a gem". Once I see past the worm and see the hook, I just stop reading. I wish these blog posts would be more upfront about their bias rather than coming across as a friendly coffee chat that turns out to be a quite biased sales pitch.

Apologies for the rant, and again apologies to the OP for catching a stray bullet here as your product is interesting. I just find this method of advertising distasteful.

> describe their own stuff as "a gem"

It literally is a gem. In Ruby, distributable packages are called gems.

You can see their gem at https://rubygems.org/gems/overrides_tracker

> I gotta say I'm sick of advertisements masquerading as blog posts.

Then friend you are on the wrong website.

A side note: You can monkey-patch binary libraries with

    LD_PRELOAD=/path/monkey-patch.so your-binary args...

In other words, even C can be like Ruby in this aspect, just more cumbersome. You need to write a C function with the same interface and compile a dynamic library. Doable but tedious.

I do that when I want to reverse. I patch-wrap the function with conditional logging and subtle manipulation. It's more flexible than just tracing.

This is something that can be done with interpreted languages (I have done it with PHP -SHAME- -SHAME- etc.).

Not so easy to do with compiled and linked software, and a great way to get thrown out of an app store, if you do it for iOS.

A proposal on how to deal with a bad habit.

Monkey patch is to patch a "monkey codebase", where it's a bug for some magic string / hard-code value.

I think we don't need this kind of runtime monkey patching as soon as the packaging system is simpler, which allows easier to fork that package.

Reply on news.ycombinator.com