Introduction

Maatkit does things differently in some ways. This wiki page is an attempt to explain some of our unorthodox decisions, and why we didn't do something more conventional instead.

Scripts and Modules

The Maatkit tools don't use Perl modules in the normal way. The normal way is to build a bunch of modules and then "use" them in scripts, like this:

use MyModule;

# Some code...

This has a variety of benefits, such as making testing easy, and making sure there is only one version of a module (i.e. the purpose of having a module in the first place, to reduce redundant code and promote code reuse). So why don't we do this with Maatkit?

It turns out that creating modules has a bunch of drawbacks, too, and these interfere with the GoalsOfMaatkit. For example:

• Modules mean scripts can't be self-contained. Even if the modules are downloaded and put into the include directories, weird issues with Perl in bizarre situations can make it a real pain to work with.
• Modules make it harder to make breaking changes to code. If a module changes incompatibly, all tools that use it are instantly broken, and we might not have the manpower to update them all.

As a result, we embed the modules directly into the tools, and update the tools when we're ready. This gives us the following benefits:

• It makes test-driven development just as easy as it usually is.
• It lets us decouple module development from tools. Tools can have different module versions without a problem.
• It makes tools stand-alone, self-contained files. Now we can download and run. This has proven invaluable.

We have some helper tools and conventions to make all this easy. See AssemblingScripts for more information.