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.
This work doesn't have to subvert Task::Kensho or an extended core or Strawberry Perl or Shipwright or anything else.
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?
There is no doubt in my mind that Perl right now tends to require a somewhat higher level of administrative and coding abilities since the toolchain, particularly installing stuff from cpan, can be tricky for the newcomer. I recently had the chance to mentor a 'just out of school' person who was trained in software development but was totally new to Perl Programming. He's definitely on the brighter side of average for people I've mentored. Our website is Catalyst + DBIC + TT with quite a bit of Moose. So I started him off on the Catalyst tutorials, DBIC tutorials, Moose examples, etc. In general he was pretty positive on the tutorials, but the thing that gave him the most pain was trying to install stuff via the cpan shell. Time and again he hit something that just would not install. Now, that was in general a bad week for CPAN, there were a couple of major Catalyst and Moose related updates and quite a few dependent distributions had not yet caught up to the changes. So most of the breakage was related to that. But there where one or two things that busted which have been known for a while.
It makes me wonder if it would not be better to think of cpan as for authors and people that need the bleeding edge (and are not afraid of cutting themselves) and start promoting something with an easier install process. For example, it's pretty easy to convert cpan dists to .deb files. I'm not sure if something like that is what you menat by a 'super' distribution.
On the other hand, bouncing all the new code and tests around do drive the community. Just some projects are better maintained than others. Even doing some basic bits like setting a 'maximum know tested' to our dependencies could help. Firefox requires this for extension authors, and it usually drives authors to actual update their stuff.
If you're willing to go binary, the PAR toolkit can do this for you. Install PAR::Dist::FromCPAN and type:
(Disclaimer: Or a slight variation thereof. Might still fail on the scary, huge things such as Alien::wxWidgets, etc.)
Then users simply need PAR::Dist (pure Perl module that can also be embedded in a script):
From the directory where the PAR file resides. Or even:
And it will be installed into the "site" directories of the given perl. This behaviour can be overridden, of course.
On my side of the debate, what I really appreciated about the Mojolicious software was not the lack of dependencies (which may or may not be a good thing), but the fact that it potentially makes it a fantastic way of introducing people to Perl without forcing them to understand what CPAN is all about. Grab Perl. Grab Mojolicious. Start hacking. That's pretty nice (assuming there was decent documentation for Mojolicious, though I assume that's coming).
The great thing is that it could be a fun introduction to Web programming. In the long run you'll have to learn more -- such as installing DBI and one or more DBDs and things like that -- but I would much rather people cross that road after they've decided if they like Perl. I don't want it to be a prerequisite.