I kind of assume that it is already installed most everywhere.

Test::Exception's functions are used in 136 test files. If you really want to avoid such a large chunk of the test suite, you might as well not run tests, or ignore the Test::Exception failures. I'm much happier demanding users to install Test::Exception. That we can be sure all the error conditions of Moose fail loudly, not quietly, on each user's machine.

That's not to say we add dependencies on a whim. I added, then quickly removed, a mandatory dependency on Test::Output. We were not using it in more than a few test files, so it was not worth the hassle of a new dependency. We know installing dependencies can suck.

Chris Prather is currently finishing up a blog post justifying each dependency. In general, we'd much rather depend on a solid, tested module than poorly implement half of its functionality.

In general, we'd much rather depend on a solid, tested module than poorly implement half of its functionality.

And there's the crux of the problem.

If you would only need to (poorly*) implement half of a module's functionality, then it means that by using it, your are also loading the other half of its functionality that you do not need. And that is deadweight.

It's like having: a people carrier for the seats; and a Ferrari for the speed; and a Rolls for the fridge; and a Citreon for the ride; and a Beemer for the Stereo; and a Volvo for the safety; and a Astra for the bike carrier; and a Polo for the iPod interface; and then loading them all onto a 40-ton car transporter and driving around in that to ensure you have everything you need!

The problem with many of these modules is that their basic functionality--the stuff you want--is relatively small, but the authors feel funny about putting a module on CPAN that only contains one or two small routines, so they add 3 or 4 other flavours of the basic routines that people "might find useful". And by the time you've loaded up a dozen dependancies, you've got 1/2 a meg of stuff you need, and 10 meg of stuff you never use.

If module authors used the Autoloader & Autosplit modules (as exemplified by modules like POSIX), so that their users could select what they need at compile time--or just stuck to providing the good bits without adding all the frills--then at least the problems of runtime bloat would recede.

(*)Why does it have to be poorly implemented? You have the good implementation as a crib. One possibility would be to produce a Moose::Utils module that extracts (and tailors) just the bits of your dependancies that you use, and ship that with Moose instead of the dependancies.

• Moose gets just what it needs--which helps your start-up delays and runtime bloat problems.
• Moose users get less dependancies and more performance.
• Moose developers and users benefit from not suffering the vagries of random authors making random changes.
• As dependancy modules change through upgrades and bug fixes, they can be integrated back into the Utils package in a controlled fashion--if needed.
• Moose benefits from not suffering breaks, because of accidental reliance upon bugs that get fixed.
• And it affords the opportunity to tune, prune and even improve those dependancies in ways that might even be useful fed back to the originating modules--without stalling your improvements waiting for author approval or tuits.

I realise that the idea of C&P reuse is an anathema most places, but re-use can be taken too far. The head/side/taillight requirements of most cars are pretty much standard, but the units are rarely re-used--even between models of the same manufacturer. The other criteria of the overall design--aerodynamics; aesthetics; etc.--dictate against such re-used despite the common requirements. The bulbs get re-used though!

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Is it just me, or is this almost another CPAN one-liner?

  use Test::Simple 'no_plan';
  sub throws_ok(&@) {
    my ($test, $qr, $msg) = @_;
    eval { shift->() };
    ok($@ =~ /$qr/, $msg);
  }
  throws_ok { die "blah" } qr/bla/, 'blah blah';
[download]

Just because lots of modules appear under Test::Exception in the CPANdeps tree (which, incidentally, you should link to as deps.cpantesters.org, not cpandeps.cantrell.org.uk) doesn't mean that they're only required because of Test::Exception.

Each distribution in the dependency tree is listed only once, so if, for example, Module::Build is required for both Test::Exception and Class::MOP, then it will only get listed under whichever 'parent' module I come across first when grovelling over the dependency tree.

(which, incidentally, you should link to as deps.cpantesters.org, not cpandeps.cantrell.org.uk)

My bad -- Dave Cantrell's site is still ahead in the Google results for "cpandeps."

And you still lose.