Trying to build and contribute to Module-Install-based-modules caused me no end of grief and frustrations in the past due to trying to chase dependencies, and lack of usability. Furthermore, Module-Install was abandoned recently and is now under-maintained and non-recommended and one should no longer use it. A better alternative would be the newer and better Dist-Zilla and I'm still using raw Module-Build which is also quite decent for some of my older CPAN distributions.
I used Module::Install for quite a long time on quite a few distributions. Although it was easier to use for most things, it was hard to find out how to do new things because the documentation was scattered or missing. This would not have been too big of a problem, except the code was also quite strange, and tracking down how any particular thing worked was difficult. Writing extensions was similarly hampered by difficulty in reverse engineering or testing. These days, I stick to ExtUtils::MakeMaker and a distribution packaging system of my own design.
The basic notion of Module::Install is to have an easier way to install your module with all kinds of things done automatically. This is a good idea, but it does so many things automatically that it's more than a little annoying. For example: if you happen to have a file called "test.pl" lying around in the directory, it will try to incorporate that into your module's set of tests, without asking you, even though it may be something you don't even want in the distribution. Or you may have some alternative or obsolete .pm files you actually don't want in your distribution, but it will try to bundle them all up and write tests for them.
Another annoying thing is its behaviour with regards to the MANIFEST file: it "kitchen sinks" the MANIFEST with every bit of cruft and every rotten old file that it can find in the directory tree. Perhaps I'm untidy or disorganized but I'm tired of having to continually fight against this module adding unwanted files and tests all over the place. This module is much too clever, and it should be stripped down to do no more than the user expects.
<Added to review August 2009>:
Here is a typical example of the irritating behaviour I described above:
[ben@mikan] My-Stupid-Module 519 $ make manifest
/home/ben/software/install/bin/perl "-Iinc" "-MExtUtils::Manifest=mkmanifest" -e
Added to MANIFEST: boo
Added to MANIFEST: bugs/bug_list.xml
Added to MANIFEST: inc/Module/Install/Scripts.pm
Added to MANIFEST: My::Stupid::Module-0.01.tar.gz
Doubly irritatingly, it tells me I should edit a file called "MANIFEST.SKIP" in order to tell it not to do all this.
No! It should never have added those files without asking in the first place. I don't want to tidy my development directory, and I don't want to have to write a stupid MANIFEST.SKIP file either.
<added to review 19 Feb./modified August 2009>
Another annoying thing is that it can break compatibility with other modules. As the other modules get updated, Module::Install stays the same inside your directory, and on repeated occasions an install failed because of an incompatible old version of Module::Install.
Frankly, it's annoying. The only reason I'm still using this instead of ExtUtils::MakeMaker is because of File::ShareDir.
I love Module::Install. I can develop code with a sensible build system that gets packaged up right alongside my module. I don't need to worry about what happens if the end-user has an old version of the build system, since I can control exactly which one gets used.
If I find bugs in Module::Install that cause my killer robots to unpack correctly and think they're chickens, then I can create bugfixes and ship them with my modules immediately. There's no awkward waiting for those bugfixes to be integrated into the upstream Module::Install releases (although they get integrated pretty quickly).
The end result is both myself and my users can spend less time with build tool headaches and malfunctioning minions, and more time building an army of killer robots to take over the world. Thanks Module::Install!
First I used this as a "drop-in" replacement for MakeMaker, then I started using it on its own and I am really glad. This means that I can handle dependencies with perl, not with whatever operating system it is going to run on. If someone downloads my module from CPAN, they will be told they need Template and Carp (in my case) without having to wait for the program itself to tell them. Plus it has the cleanest syntax you could hope for.
"The above is obviously a mutation of the monumental speech by great Martin Luther King (web66.coled.umn.edu/new/MLK/MLK.html). While the contexts are vastly different, I feel that there are some serious parallelisms."
-- Brian Ingerson
No, there are no "serious" parallels at all, just an offensive pastiche that cheapens an heroic moment. Please update it.
Otherwise a great module: reassuring to see the MakeMaker limitations being addressed, even if in parallel to other replacement efforts.
Module::Install is a great module, but for a while there it seemed to have been abandoned.
It still has quite a number of outstanding bugs, but I spose I can't really complain about these any more, given that I've got commit rights to the repository now :/ And I believe the author is willing to do the same for others who want to address these bugs.
Still, you might want to be careful if you want your module to support lower than 5.6.0, and the documentation can get a bit weak.
But all in all I now think that with enough users and more attention, these bugs can be resolved. The idea and the design are completely sound and have always been so, it just needs some TLC here and there.
I really like this module because it allows me to do two things that I want:
1) Include in a distribution the modules that are only needed for testing so that the user doesn't have to install them.
2) Create "real bundles" that actually include everything so that they can be installed without a network connection.
The only problem for new users is that the documentation is not as complete or as clear as it could be. There is an article in The Perl Journal (June 2003) by Brian Ingerson that helps a lot, but it requires subscription.