Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

RFC - Module::Cooker - UPDATE

by boftx (Deacon)
on Dec 02, 2013 at 05:39 UTC ( #1065224=perlmeditation: print w/replies, xml ) Need Help??

Update: Version 0.1_1 has been released to CPAN for testing. Documentation is fairly complete, but more love is needed. The executable should work as described in its POD. Help with a test suite for the executable would be greatly appreciated. I expect it to pass on all versions of Perl greater than or equal to 5.8.8, and will not be surprised if it passes 5.6.1. The alpha release can be found at

I come to you today asking for a peer review of what I hope will be a useful module to those who need a simple way to create a skeleton CPAN module. The code is NOT complete by any means, but it will pass the basic tests and a module created created with it will pass its tests, as well. I hope to have it completely finished on Thursday but want your feedback now in case I am going down the wrong path somewhere.

Like most of you reading this, I have used various tools such as h2xs, Module::Starter, Module::Maker (and have examined Distribution::Cooker) to create skeleton distributions.

And like most of you (I presume) I have found each to be lacking in some area.

Hence, Module::Cooker. It draws upon what I consider to be the best of the aforementioned tools and adds a bit of my own. Specifically, I have strived to make it as easy as possible to create custom skeleton templates that meet the needs of different types of modules.

I want whatever feedback you have, good or bad. If anyone wants to be a co-maintainer I wouldn't complain about that, either. :)

I hope to release this no later than this Thursday since I will be on the road to Houston on Friday morning.

It helps to remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.

Replies are listed 'Best First'.
Re: RFC - Module::Cooker
by kcott (Canon) on Dec 02, 2013 at 07:57 UTC

    G'day boftx,

    I wondered if this had the ability to add new modules to a distribution. For example, you create Some::Module::X; later you want subclasses Some::Module::X::Y and Some::Module::X::Z.

    I looked through the code (albeit briefly) and couldn't find anything like this. The die "Distribution directory already exists: " ... in _process_template() rather suggests it's not possible.

    I think this would be a nice feature to have. Of course, during my minimal tour of the code, I could have missed it; if not, perhaps consider for a later version.

    As a general comment, the code looks well written, nicely formatted and easy to read. I haven't downloaded or tested any part of it; so, that's really just a (positive) report on style.

    -- Ken

      You are correct that it does not have a mechanism for adding a module to and existing distro, yet. I read a couple of comments elsewhere that said the desire for that feature was the inspiration for writing a sub-class to enable other modules to do that. Thinking of the general use-case in a mature project environment that is something that might be needed. I have tried to keep that in mind for future enhancements.

      It helps to remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.
Re: RFC - Module::Cooker (File::ShareDir::Install)
by Anonymous Monk on Dec 02, 2013 at 08:37 UTC

      Actually Dist::Inkt is unlikely to be much help; it only does one job: produces a tarball suitable for uploading to CPAN from the project directory. (That includes building META.yml, META.json, Makefile.PL, etc.) Creating a new project directory from scratch is something outside its mandate.

      However it has a companion project Dist::Inktly::Minty which does that; it should be fairly easy to subclass to do what you want. (A couple of subclasses are bundled with it.)

      Update: as a general design note, if you do publish Module::Cooker... don't waste your time making it super-configurable with config files, etc. The end-users it is aimed at are Perl programmers; they are not opposed to writing Perl to get something done. So just make it easy to subclass - this is a far more powerful form of extensibility. Break everything up into small methods that can be overridden in subclasses; document them, the arguments they take and what (if anything) they're expected to return. Make sure that your command-line tools support a --cooker=Module::Cooker::MySubclass option to allow users to indicate hey want to use a particular subclass of Module::Cooker rather than the base Module::Cooker package.

      use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name

      I'm not quite sure what you mean. I am using File::HomeDir in the script to get what I hope is the user's home dir so I can locate an optional local config file. With regards to data files, Module::Cooker places its data files under its own directory, see _basename_dir, but that can be overridden by specifying a local data dir if desired.

      It helps to remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.

        I'm not quite sure what you mean ... Module::Cooker places its data files under its own directory

        Pretty much what I said, don't do that, use sharedir , sharedir is the "official" way ... perldoc/pod2html... will all find your "data files" and treat them as real perl modules ... because they live in the module tree and are named like modules ... you avoid that with sharedir , its why its the "official" standard :)

        Also remember to consider version-ing or even theme-ing your template sets ...

Re: RFC - Module::Cooker
by educated_foo (Vicar) on Dec 02, 2013 at 14:28 UTC
    If I were you, I would ask myself whether I was trying to create a tool to make it easier for me to create a module, or to create a tutorial for newbies. For the former, any developer who writes enough modules to make it worthwhile will probably write his own script.

    lib/Module/Cooker/default/ is rather unhelpful for this: it generates 80 lines of stuff, most of which I would have to delete every time I created a module. To make your module useful, I would have to write a script to immediately delete useless things like "Stub documentation for \% %\...," or read about how to create my own template which only included useful things.

Re: RFC - Module::Cooker
by taint (Chaplain) on Dec 02, 2013 at 23:22 UTC

    OK I can see on one hand, if you're a prolific Module Author. You've likely already written, or chosen a skeleton creator that suits you best. OTOH, if your a seasoned Author, but not terribly prolific. I can imagine one might look to something else, rather than write their own, that seems to best suit their style. Then OTOH, there's the "aspiring author". That has a keen sense of Perl, and is looking to cut their teeth, on their first Module.

    In my humble view. I see this as potentially appealing to the latter two mentioned. Providing enough flexibility for those who could but might rather not write their own. Or as a easy "first step" for those whom are not already knowledgeable in the ways of the great CPAN.

    So, to me. I wonder if it might not be wise to break it up thusly:

    Module::Cooker Module::Cooker::Templates Module::Cooker::License Module::Cooker::Tutorial
    This construction/layout would then have the potential to appeal to a broader group. Making for easy useage, no matter your needs. Module::Cooker::Templates could provide customizable templates that anyone could (want) to use. Whereas Module::Cooker provides a "minimal" base, from which to start from. The rest, I think, speak for themselves. :)

    You asked for input, and you received. :)


    #!/usr/bin/perl -Tw
    use Perl::Always or die;
    my $perl_version = (5.12.5);
    print $perl_version;

      You're reasoning on the target audience is similar to mine. With regard to structure, one of the things going into the script is a --copy option that would copy the specified template profile to the user's local modcook directory so they can modify it there to override the module templates.

      It helps to remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.

        That Template thing is potentially a tricky bit. Flexability, and the ability to switch on demand, based on the users need(s). I think should be addressed. To my knowledge, there really isn't anything that currently addresses this as effectively, as it could. This option, if done correctly, could possibly set it apart from the others already available.

        Then there's the versioning strategy. Based on what? Everyone has their preferred strategy. While some, may choose none -- if only for a "one off".

        Just some thought's that come to mind.


        #!/usr/bin/perl -Tw
        use Perl::Always or die;
        my $perl_version = (5.12.5);
        print $perl_version;
Re: RFC - Module::Cooker
by Laurent_R (Abbot) on Dec 03, 2013 at 19:02 UTC


    I have written quite a number of modules, but none of them has made its way to the CPAN. Mainly because most of these modules were very specific to our environment and would not be useful outside that context. But at least two modules that I wrote recently could be useful to others, if I only knew how to package them for the CPAN. Yes, I was not really convinced by the existing modules to build such skeletons, but quite possibly because I used them wrongly. If your module makes things easier, then I am definitely interested. I'll try yours, but don't expect an answer from me before at best the next weekend.


      When it comes right down to it, there is really only one file that is usually easier to have a tool create for you: Makefile.PL

      Once that is present (containing the proper commands for ExtUtils::MakeMaker) the process boils down to this:

      perl Makefile.PL make manifest make disttest make dist make distclean

      At that point you should have a tarball ready for upload to PAUSE.

      What the various tools do (including Module::Cooker) is create a full skeleton structure that just happens to include Makefile.PL. Based on what you (and others) have said, I should add a means to only add any missing files such as Makefile.PL to an existing directory structure.

      It helps to remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.

        This also assumes that your directory layout is like a typical CPAN dist. Otherwise you may need to make tweaks to Makefile.PL so it can find your stuff. (Or better yet, rearrange your files.)

        Makefile.PL # in the project root directory lib/Foo/ # modules named like this script/foobar # scripts like this bin/foobaz # ... or this t/foo-bar.t # tests like this xt/foo-baz.t # extra tests like this
        use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://1065224]
Approved by Lady_Aleena
Front-paged by tye
Corion munches on the traditional German winter fruit, strawberries. Imported from Spain at the price of EUR 0.77 per 150g - not really cheap but surprisingly good for a winter produce
Discipulus straberries portable edition
[Corion]: Discipulus: Haha ;) I hadn't made the connection to Strawberry Perl at all ;)

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (6)
As of 2017-01-20 10:23 GMT
Find Nodes?
    Voting Booth?
    Do you watch meteor showers?

    Results (174 votes). Check out past polls.