PMpmarreck·Oct 22, 2025
https://github.com/pmarreck/pachinko
Note: Have not touched in > 13 years, so there's that lol
At the time I was working on a million+-line Ruby codebase at Desk.com. We were in a situation where people were monkeypatching out bugs in dependent libraries that weren't patched upstream yet, and then forgetting about them, and they would eventually end up causing problems that were difficult to run down. So I wrote this tool to basically organize and "vet" the monkeypatches BEFORE they were applied, using a runtime test (at app startup/stack load) to see if it was still necessary to apply, and if not, write a warning to stderr. Otherwise, it would re-apply it (but also notify to stderr). I wanted these patches to be a bit noisy so that they wouldn't be forgotten about and so they would be removed once no longer necessary.
Of course, what I'd
Read the rest
NOW do instead is 1) fork the library into my own repo, 2) apply the patch, 3) tell my app to use my fork, 4) have some rigorous process to re-depend back on upstream somehow once things had settled again. That would keep things more easily traceable.
I more or less left Ruby and have been doing Elixir for years now, because I realized that functional/declarative is the way to go for long-term code maintenance (and general ease of testing/debugging, and lower production of bugs per LOC written, etc.).
Regarding the naming, I thought that throwing a bunch of monkeypatches at a codebase was kind of like dropping metal balls in a pachinko machine, in that the outcome would be non-deterministic (we avoid non-determinism at all costs!). For example, there was no way to guarantee the order that they would apply in, in case there were conflicts (which also couldn't be detected at the time of application, only via specific unit testing)... If I was smart (I don't remember if I did this or not), pachinko would intentionally apply the patches in a randomized order, so that latent dependency issues would be floated to the top...