After ranting about dependencies, I started thinking (which is not the same as ranting by any means!).

Other systems have long dependency chains, but people don’t complain. Specifically, I’m thinking of Debian, which has great tools for tracking and installing package dependencies.

I used the cool debtree tool to create a dependency graph for gimp. Check this monstrosity out!

That’s a lot of dependencies! But it isn’t considered a problem, and I don’t think you’ll find anyone out there complaining that gimp’s dependency chain is “too long”.

The difference is that debian packages always install cleanly. Install failures are rare, and are fixed very quickly.

By contrast, modules installed via the CPAN shell fail pretty often. This is a case of our own culture biting us in the ass. Debian packages do not run any tests on install. The package maintainers are just responsible for making sure that the package installs cleanly. If the package has bugs, the maintainer fixes them (or gets upstream to fix them) and makes a new package. In most cases, there probably isn’t even a test suite for the maintainer to run.

Perl has a great culture of testing. We expect all modules uploaded to CPAN to come with a test suite, and we expect modules to run their tests on install and to pass. I love that we have such high standards, but these standards are not without problems. When a module fails its tests, the person doing the install isn’t in a good position to handle it. In many cases, they could probably force the install and use the module, but how could they know that?

I’m not sure what the solution is. One possibility is for module authors to cut back on the number of tests that they run on install. We could start moving most of the tests to an “authors only” test directory. That seems kind of sad though.

Maybe there’s also an education component. We could tell people that it’s ok to force an install of a dependency, as long as the module they want to install passes its own tests. For example, if I’m installing Catalyst, I can probably live with a failure in the Data::Dump test suite, as long as Catalyst works.

Maybe the CPAN shell could have a mode where it simply ignored dependency test failures, but delayed really installing them until checking that the originally requested module passes its tests with said dependencies.

This solution accounts for the reality that everything has bugs. The Catalyst authors can work around bugs in their dependency chain, and all you as an end-user really care about is that you can use Catalyst as advertised.

I’m not sure what the best solution is, but I do know that the solution is not to demand that module authors reduce their dependencies “on principle”. Encouraging wheel reinvention reduces code quality, even though it could give the appearance of less failure. This would just move failure from CPAN install time to “using the module full of reinvented crap” time.

Dear whiners-about-dependencies,

Please stop whining.

Recently, there was a thread on Perlmonks which included the quote, “the dependency chain on Moose and MooseX is *long*.”

What is “long” here? Moose really doesn’t have that many dependencies. Also, conflating Moose with a bunch of Moose extensions is just weird.

Chris Prather then wrote a blog post explaining why Moose has each dependency. That was nice of him, but I’m not sure addressing the whiners like this is worthwhile. Moose’s dependencies need no justification. We Moose authors thought we needed them, so we used them. End of story.

I really don’t understand why people complain about dependencies. CPAN is what makes Perl great. It certainly isn’t the Perl 5 language itself, which is getting a bit long in the tooth. Without Moose, Catalyst, DateTime, DBIC, etc. how interesting would Perl 5 be compared to its numerous competitors? If you want a brilliant language where you can write everything from scratch, I suggest Haskell.

If you’re going to use Perl, you need to figure out how you will handle dependencies for your applications. There are a lot of options for managing them, including:

• Writing everything from scratch instead.
• Copying modules wholesale into your source tree.
• Copying tarballs into your source tree, and installing them as part of your build process.
• Using/making packages for your system of each dependency.
• Maintaining a local CPAN and installing from it.
• Installing things from CPAN directly and hoping nothing breaks.
• Some combination of the above.

These are all possible solutions (though the first is for idiots). Whining to module authors that they have “too many” dependencies is not a solution.

As an aside, at what point would the whiners stop whining? If Moose had half as many deps, would the whining end? I doubt it.

I will offer one sop to the whiners. If you as a module author are depending on a module, I hope you’re willing to help maintain that dependency. That means passing on bug reports (people will report a dependency’s bugs to you), writing patches, and generally helping keep your dependency chain installable.