huge dependency radii, or why I stopped using Catalyst

More than a year ago, we were working on (re)developing some code for UI for our units. Original UI code had been in Catalyst framework, an MVC system for Perl. I like Perl, it makes rapid application development easy, and reasonably painless. CPAN makes avoiding coding things yourself pretty easy. Short side trip. A dependency radius is the measure of the number of additional things unrelated to your source code itself, required to build or operate your program. These could be libraries, or functions. Or anything. Define: Landman’s theory of inverse utility of dependency radii as the measure of a programs build complexity … if you cannot build anything in the huge dependency radius, your code may never run. Therefore, increasing dependency radius is a very … very bad thing to do without a very good reason. There is a corollary to this. And its kind of obvious. Almost blatant. Ease of installation is an inverse function of the dependency radius. There is another corollary to the theory. And its very obvious. Ease of deployment is an direct function of the ease of installation. Why am I telling you this, and what has any of this to do with anything? We are replacing our Wikis. We’d been using Dekiwiki, but it is effectively impossible to upgrade. It is impossible to install a framework and then point it our database with the old wiki contents. And I am tired of dealing with broken software like Mono and PHP that have combinations of security holes, longevity questions, and other issues. Not to mention a massively overly complex design (the dekiwiki architecture) for something that is ostensibly simple. Sure, they could argue with us over this. Say its needed and all that. We’ll have an answer to that soon (assuming I have time to write code soon) that shows this not to be the case. But thats the reason we are looking at new wikis, because the old one(s) are in a non-resucitatable state, and the only way for me to recover data from them is direct sql queries against the databases. Yes, this is wrong. This is very wrong. A design so brittle that it cannot leave a database in place, and point to it on installation? Yeah. Want to remove that. But I am trying wikis. And I am revisiting MojoMojo. Which is based upon the Catalyst web framework. Its curious that the person who wrote this, is now also using the Mojolicious web framework. Will talk about this in a moment. Catalyst, and the MojoMojo application have a GIGANTIC dependency radius. Following the install guide to the letter results in a failed installation. MojoMojo is built upon Catalyst, which is itself built upon many … many things. Understand, I liked Catalyst in the past. I used it. We have code bases which ran it. But I found deploying apps was incredibly hard. Module updates would sometimes break apps in odd ways. Some of the automated test code (::WWW::Mechanize::) didn’t work, wouldn’t build right, and this caused cascading failures. So I tried Mojolicious, found it superior in all aspects. Installation was a snap, productive very quickly, deployment is simple, very low dependency radius. But MojoMojo is in Catalyst. And I just tried installing it again. Using two different Perl’s on Centos 6.3.

  Failed tests:  2-3
  Non-zero exit status: 22
  Parse errors: Bad plan.  You planned 9 tests but ran 3.
Files=58, Tests=271, 16 wallclock secs ( 0.24 usr  0.05 sys + 13.99 cusr  0.83 csys = 15.11 CPU)
Result: FAIL
Failed 39/58 test programs. 36/271 subtests failed.

and

  Failed test:  2
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 9 tests but ran 3.
Files=58, Tests=230, 38 wallclock secs ( 0.14 usr  0.08 sys + 34.44 cusr  1.60 csys = 36.26 CPU)
Result: FAIL
Failed 31/58 test programs. 34/230 subtests failed.

I had allotted 4 hours for testing this. I have used up 1 so far with failed installation. Will spend one more hour on installation, and if I can’t get everything sorted out, I won’t waste any further time. The cpan MojoMojo took well over 15 minutes, before failing. On a very fast machine with lots of ram.