4 ms·

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 initial

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.

ufmace 4y ago
> 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+.
- nevinera 4y ago
  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.
  - ufmace 4y ago
    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.
    - nevinera 4y ago
      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.

ufmace 4y ago

> 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+.

nevinera 4y ago
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.
- ufmace 4y ago
  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.
  - nevinera 4y ago
    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.