First: Who uses module-starter? Who copies an existing project and throws away most of it, then edits what's left? Who has another method? Please think about this and include your answer in any reply.
I'm deeply unhappy with module-starter and Module::Starter*. I started using them because there is indeed a lot of boilerplate that needs to be created for each project. It seemed better to set this up programmatically than by copy-edit; and I still believe this. But I've started my last several projects by hand.
I'm aware h2xs has been used for this purpose. I'm agin it, on principle: not the primary purpose of the tool.
Here are a few issues I'd like to clear up:
- Why is module-starter so complex? This seems to me to be merely a matter of copying a set of templates and making substitutions of placeholders. The Module::Starter distribution contains five modules and a script.
- Why is module-starter so inflexible? Adding a new template file should be as easy as dropping it into the master template folder. It's not. Adding a new placeholder type should be as easy as defining the variable somewhere. It's not. Much of the boilerplate produced actually is hardcoded right into one of the Module::Starter modules, as heredocs. I'm talking pages of it.
- Why does Module::Starter do so little? Part of the complexity seems to be to allow a variety of plugins to do the real work. There isn't even a standard method of adding a new module into an existing project; for that you need Module::Starter::Smart. I'd rather see the base tool get the job done... although I agree it should be extensible.
- Why is only one config file supported? What if I want several "profiles", multiple template sets? Not all my projects are alike. Why is that single config file in a superficially simple, fusty format? Why can't I supply a config file in any one of the accepted config formats, or in plain straight Perl?
- Why the lengthy command line invocation? Yes, yes, I know many are quite happy constructing lengthy commands. But this interface gets less fun the more options must be passed in; and more difficult the less often a given tool is used. I don't start a new project from scratch every week. This is a case for a little interactivity, when demanded.
I suppose I can subclass and redefine the guts to do what I want. This is the approach taken by Module::Starter::Plugin::Template and Module::Starter::PBP. I don't feel it's worthwhile to cram a new tool into a difficult API.
I'm thinking seriously of starting work on a replacement. This will use the widely respected Template::Toolkit as backend for placeholder substitution and Config::Any to allow developers to edit multiple config files in their choice of YAML, JSON, INI, Perl, or what-have-you. There will be the expected lengthy command line interface but also interactive setup of configuration. And the whole thing must be kept simple! This is, after all, a way to start a Perl project; at some point you have to go to work and write code.
Before I roll, I'd like to hear what alternatives make other Monks happy.