A good question I ask myself is: Can I vendor it in? If I cannot, that’s usually something standard, but also a complex domain (crypto, network protocol, platform framework,…). Anything else, I assume it’s only a short term gain, so I make sure to explore the library and get a good understanding of its internals.
I am failing to find it, but Simon Willison had a post where he vendored some small (<1000 line) blob of code instead of adding it as a dependency. The trick was that he had some Github action(?) automation which would automatically check if the vendored version ever fell out of sync with upstream. Get the benefits of vendoring while minimizing your actual support burden.
Only a realistic strategy for small bits of code, but I have considered do the same for a few utility libraries which are a focused niche, but subtle enough that you would rather outsource the complexity.
Vendoring is somewhat an answer, but not always.
I have some python code, vitrualenv is an obvious solution. However, older modules depend on older python3.9 behavior. And python 3.9 EOL is October 2025.
