This is the wrong direction. I can say this having written a monkeypatching management library in Ruby a long time ago.
replies(1):
It's a bit like OverlayFS for Python modules - it allows you write modifications for a target module (lower) in a new module (upper), and have these combined in a new virtual module (mount).
It works by rewriting imports using AST transformations, then running both the lower and upper module's code in the new Python module.
This prevents polluting the global namespace when monkey-patching, and means if you want to make changes to a third-party package, you don't have to take on the maintenance burden of forking, you can package and distribute just your changes.
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 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...