Tautology alert: Perl 5 is the toolkit; CPAN is the language.
The background: Mojolicious is a Perl 5 web framework with no non-core dependencies. Curtis Poe praised Mojolicious's marketing and remarked that its lack of dependencies could be an advantage. Adam Kennedy used CPAN analysis techniques to remove unnecessary dependencies from Padre (and Mojolicious used similar techniques to make their software even more dependency-free on older versions of Perl 5). John Napiorkowski reported on his work to solve dependency problems.
There's a philosophical question here.
Jay Kuri made a distinction between internal and external dependencies and suggested embracing dependencies. Yuval Kogman discussed how dependencies improve encapsulation and reduce reinvention through nasty hacks.
You might get the idea that there's a debate over the use or avoidance of dependencies.
That's not the debate. That may seem like the debate, but that's the wrong debate. It's a false dilemma. We won't solve the philosophical problem of "When is it right to reuse external code versus patch it locally versus write our own version?" That's one of the debates of art in software development. (Like debates of art in other endeavors, the right answer is "It depends." (I make an exception over debates of art in literature, where the right answer to "Is fanfic an abomination?" is "Yes."))
The real debate over dependencies is a question of change management. The real, underlying questions over dependencies are:
- Can I install dependencies reliably on platforms I care about?
- Do the necessary tests pass for all of the required dependencies?
- What happens when a dependency changes?
- What other dependencies does one dependency require?
- What implications are there from using the entire dependency graph, legal or otherwise?
- What support implications are there from using the entire dependency graph, legal or otherwise?
The Waterbed Theory of complexity argues that, all other things being equal, simplifying one part of the system -- the development and maintenance of the program which embraces dependencies, for example -- tends to increase complexity somewhere else.
In many cases, that somewhere else is a burden on installers and users of the system.
The real debate is over where that complexity belongs.
The false dilemma is that it belongs neither on the maintenance side nor the installation side. We could resolve most CPAN dependencies statically with existing tools, providing single-installation superdistributions we believe will work reliably for average users.
CPAN is great in many ways. CPAN installer dependency resolution tools are flexible and powerful for people willing to learn how to use them. They're good for power users. They're great for people capable of testing the latest versions, then filing bugs and writing patches to fix inevitable oversights when things go wrong.
All we need to do is tie together some existing tools, identify distributions without declarative dependencies (or with incorrect metadata), and encapsulate the complexity of installation into complexity of bundling. We don't even have to remove the fallback -- you don't have to use a system unless you want it.
Is there a downside?