3 ms·

I have heard this exact sort of thing frequently and it’s always from upstream devs who literally want to decide exactly how downstream do everything and refuse

I have heard this exact sort of thing frequently and it’s always from upstream devs who literally want to decide exactly how downstream do everything and refuse to accept reasonable changes from people using their stuff in the field who just need it to work slightly differently from the upstream version. I don’t use Ruby, but I have had to monkeypatch a lot in Java and literally every time I would have preferred not to, but did it because I had to. I once had a fun conversation with a head of product for some software once where he said a monkeypatch is ok for a spike when you’re testing something but you should never monkeypatch in production and I explained I had 14 monkeypatches to his product currently in production and you couldn’t even log in with ssl to his product without monkeypatching out some parts of the SSL cert verification code because the cert verification wouldn’t work with certs issued by an enterprise CA (rather than a trusted root CA). In all of these cases these were patches that had been submitted upstream that I didn’t want to have to maintain but had been rejected by upstream because my use case wasn’t what the dev thought the general use case was. That’s fine btw and exactly why monkeypatching is useful.

masklinn 4y ago
> refuse to accept reasonable changes from people using their stuff in the field who just need it to work slightly differently from the upstream version. On the other hand reasonableness is in the eye of the beholder. As both user and victim of monkeypatches, i’d rather nobody had to but there’s not always an agreement to be found (or feasible at all). On that point I like Cargo’s support for local versions / forks of dependencies, it provides a cleaner and less fraught support for patching your upstream (whether you ultimately fork or not).

masklinn 4y ago

> refuse to accept reasonable changes from people using their stuff in the field who just need it to work slightly differently from the upstream version. On the other hand reasonableness is in the eye of the beholder. As both user and victim of monkeypatches, i’d rather nobody had to but there’s not always an agreement to be found (or feasible at all). On that point I like Cargo’s support for local versions / forks of dependencies, it provides a cleaner and less fraught support for patching your upstream (whether you ultimately fork or not).