If there's a debate between embracing the CPAN and relentlessly avoiding dependencies, my taste runs toward the former. Certainly avoiding unnecessary dependencies is a valid strategy, but no other reason for avoiding useful dependencies argues, in general, more strongly than the reasons for using dependencies.
Consider some of the most successful CPAN distributions: DBI, DateTime, and Test::Builder. On their
own, they provide many more features than most projects ever need (I care
mostly about PostgreSQL access, continental US time zones and holiday
schedules, and often only a handful of Test::* modules). I could
probably reimplement most of the code I need myself with fewer
abstractions unnecessary for my needs, less code overall, and increased ease of
installation for the users of my software, but I don't. Probably neither do
most of you.
I see Moose the same way. So do some of you. While I could write an object system myself (I've contributed to a few on projects you've heard of), it's not worth my time to do so when a perfectly good system already exists—a better system than I'm likely to write, given the time I have available.
More than that, installation is once, but sharing is caring forever.
In other words, the hassle of figuring out how to bundle or mark for installation one or more dependencies is a single cost. The maintenance burden of my reinvented libraries lasts as long as I allow those reinventions to exist. If my users are capable of using a custom CPAN (or CPAN itself) to install my software as bundled for the CPAN, dependency management has almost solved itself. The whole of the CPAN ecosystem, including testers and platform smokes and bug tracking, supports those dependencies.
I can release my own reinventions to the CPAN to take some advantage of these network effects, but compare the contributor lists to the three distributions I mentioned to the contributor lists of single-use distributions. The correlation exists: the more widely used a dependency, the better chances of it meeting user needs. The more users (and the more diverse users), the more chances to find bugs and infelicities. (You can make the case that CPAN Testers could use rigorious stochastic analysis to improve the confidence and utility of its coverage, but the world of free software tends to work best when it trades small amounts of volunteer labor, properly applied, for trivial problems.)
This is not an absolute guarantee, of course. For example, security flaws may exist in a widely used dependency where a careful reimplementation may avoid the problem&mdash. Best judgment applies, but, ceteris paribus, I trust a project more upon learning that it does one or two things well instead of attempting to do everything itself.
I disagree almost entirely with the notion of CPAN developers constantly reinventing the wheel for their CPAN modules.
One of Perl's biggest assets can be one of the biggest barriers to newcomers: CPAN. CPAN has a lot of dead, unmaintained code on it from people who have rolled their own object system, or rolled their own OAuth implementation for their projects, because other, more generic solutions were just too "bloated."
While choice is good, it makes it significantly harder to find modules that are not only maintained, but also not horribly, horribly broken. Dependencies are good things (except for embedded systems), since developers don't need to spend the additional time to maintain their custom CPAN reinventions, and can put more work into developing their core code.
When I write Perl, I try as hard as I can to find CPAN modules to do as much of the work for me, because that (theoretically) reduces the amount of code that I need to audit, maintain, and be responsible for.
If there's a good reason to have an alternative, like Dancer to Catalyst, well fabulous, go for it. But it's difficult to find modules to do simple things on CPAN because the preponderance of old, unmaintained code on it.
I think that CPAN gives me the tools to detect unmaintained code, as well as other source repository sites does, or better than them.
And sometimes, unmaintained code doesn't mean usefulness code. Sometimes you can download the distribution, look at the implementation and dependencies and tests (and of course the issues open). Thats better than nothing.
And sometimes, wonderful people, take over unmaintained code and makes it bright again or start solving open issues.
Anyway, if you have some idea about howto improve the CPAN tools to identify unmaintained code, I'm sure that people will be grateful to listen your ideas.
Greetings.