|more useful options|
Re: Alternatives to Module::Starterby rjbs (Pilgrim)
|on Jan 20, 2012 at 23:15 UTC||Need Help??|
Hi. I did a lot of early work on Module::Starter, and can answer some of those questions. I also wrote something that I use instead, and can tell you something about that.
The original module-starter program was very simple, and had a number of routines named things like "build_Makefile_PL_guts" that would, as you expect, take a few configuration bits and return the whole file to be generated. It did exactly what its original author wanted, and was better for me than most anything out there at the time. The problem I had was that it put things together a little differently than I wanted, and it wasn't easy to customize its output.
The first thing it needed was for the templates to be replaceable. I did that by making the module-starter command accept an optional class name to use instead of "Module::Starter." That way, I could write a subclass that replaced the "guts" methods. (As I recall, this also necessitated the conversion of the package Module::Starter to act like a class.)
Once I'd done that, I realized that I didn't really want to hardcode my templates. I wanted to store them in files that I could edit without breaking my library's syntax, or swap out between different projects. This meant writing the Module-Starter-SimpleStore distribution, and doing more refactoring. I also wrote some other stores that I don't think I released, like one for keeping your templates in a Kwiki.
The problem with all this was that I was doing all the work on something that wasn't built for it, and I was only thinking one step ahead. The program started out quite simple, and I tried to grow it into something complex without re-engineering to make room. I was young and foolish! Once the problems became clearer to me, I started to dream about writing a new kind of Module::Starter system that would build up "kits" of files in memory, then write them out. They could have dependency on each other, and could be more interesting than just a name and contents. That's when Module::Starter::Simple was born. I never went much further than that, though. I mucked about, but it was clear that I needed to radically break backward compatibility, and I didn't feel good about that.
I stopped using Module::Starter, now a good bit more featureful, but definitely a lot more complicated to use, and I went back to copying and existing dist and editing and renaming stuff. Once in a while I'd be tempted by some other Module::Starter-like system. David Golden's never-released Module::Boilerplate really hooked me for a while. Nothing ever really satisfied me, though.
A few years later, I realized that I didn't really want much boilerplate anyway. I hated having to edit all that crap: the VERSION section in the Pod, the copyright years, etc. I hated thinking about making a MANIFEST or MANIFEST.SKIP. This is when I wrote Dist::Zilla, which let me not write the boilerplate at all, and instead have it crammed in just in time for each release. With that done, I deleted a large amount of non-code in many of my dists and started using Dist::Zilla for releasing them -- it would now add the kind of boilerplate Module::Starter made, but I'd almost never have to see it in my editor.
This changed how I felt about things like Module::Starter. Now I didn't want a better one at all. I didn't see any need. I wouldn't need any boilerplate. To start a new dist, I literally just ran mkdir and started editing code. Done.
Despite this, every once in a while, someone would ask when Dist::Zilla would start "doing what Module::Starter does." I would scoff: never! Module::Starter totally misses the point! People kept asking, though, and not just random people. I'd get this question from people who I knew were smarter than I was. I started to ask why on Earth they'd want such a thing. The answers were great.
Some people wanted it to create the dist.ini file -- which was fine, but not a very interesting answer. Someone else suggested that a Dist::Zilla-based system would allow things like creating a Git (or Subversion, or whatever) repository during dist creation; or checking that the name wasn't already in use; or starting a work-tracking timer. Or all kinds of stuff. Dist::Zilla provided a lot of generic framework for plugins, and having a pluggable "make a new dist" command seemed quite useful.
So I wrote it.
I really don't use dzil new for very much. Mostly, I use it to get an initial Git repository made, although I'll probably start using the "...and make a Github repo and push it there" plugin sometime soon. Using Dist::Zilla instead of Module::Starter, even if you don't use Dist::Zilla to release your modules, seems like a pretty sane bet to me. It's really, really easy to build new templates, if that's the only behavior you want. If you want lots of other behavior (register it at Ohloh; announce it on your Perl Monks scratchpad) those are easy to add, too.
...but if you don't want to bother with Dist::Zilla, there are plenty of other systems on the CPAN. Module::Start, Distribution::Cooker, ExtUtils::ModuleMaker, and probably a dozen more. I wish you the best of luck in finding the one that floats your boat!