|
|
|
|
|
by geofft
1643 days ago
|
|
Huh, it's the other way around for me. Just about every nontrivial Python project I write requires at least one third-party library, and one much more complicated than attrs at that, that I may as well use attrs too. All the complexity of having dependencies - both distributing them / setting up a virtualenv / etc., and whatever scrutiny I wish to do on dependencies - have a pretty big constant term from doing them at all; doing them for one more dependency (and one that doesn't change all that often) is only a bit more work. Granted, I'm not reviewing my third-party dependencies line by line when I upgrade them. But also I'm more afraid of the security risks of large amounts of in-house code that aren't exposed to public scrutiny, and so a policy that dissuaded the use of even high-quality and well-regarded third-party dependencies seems like it would do more harm than good. Besides that, it helps that I happen to have met the maintainer of attrs at PyCon (and attrs has only one uploader in PyPI), and therefore I'm less concerned about supply-chain attacks against it, whether of the malicious-maintainer variety or the maintaner-got-scammed-or-hacked variety, than, again, most of my other dependencies whose maintainers I've never heard of. I'm not sure this scales particularly well, but I do feel like there's still something in the open source community being a community. |
|
Supply chain attacks are a complex and nuanced topic so there are plenty of reasons to be thoughtful about adopting new dependencies, but it's definitely not as simple as "just use the stdlib for everything".