Re^4: Does Perl have a baked-in memory llimit?

[einhverfr]

Most software these days has a fairly large number of dependencies, which is part of the reason software bill of materials requirements are becoming a thing. Certainly managing that is a consideration. On the other hand.... Popular CPAN modules provide a lot of benefits including:

• More eyes are likely present
• More hands to take over where needed

My advice instead is to read through code of many of the dependencies you want to use and then decide if you might want have to maintain that code. The bar is far lower in test cases (where I usually use File::Slurp) than in production (where I don't).

Reading through the code gives some sense though of why not to use File::Slurp.....And I do pity the guy who took over maintaining it. And I say this as someone who has taken over CPAN modules in the past over maintenance needs....

[eyepopslikeamosquito]

> The bar is far lower in test cases (where I usually use File::Slurp) than in production (where I don't)

I feel this is a dangerous mindset, especially in larger organisations, as indicated by these two points from Effective Automated Testing:

• Automated test suite needs ongoing maintenance. So test code should be well-designed and maintainable; that is, you should avoid the common pitfall of "oh, it's only test code, so I'll just quickly cut n paste this code".
• It's vital to quarantine intermittently failing tests quickly and to fix them quickly ... only returning them to the main build when reliable (if you don't do that, people start ignoring test failures!). No broken windows.