in reply to RFC - Module::Cooker - UPDATE

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

[download]
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. :)

--Chris

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

Replies are listed 'Best First'.
Re^2: RFC - Module::Cooker
by boftx (Deacon) on Dec 02, 2013 at 23:30 UTC

    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.
[reply]
[d/l]

      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.

      --Chris

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

        I think I'm just going to ignore the versioning issue so far as trying to create default "ignore" files. Module::Starter has options to do this, but I think it is easier for the user to just create a local profile dir and add whatever files she thinks are needed. The standard M::C templates will be pulled in if they are not in the local dir (assuming the profile name exists in the standard distro) so it should be trivial to add one's favorite versioning config files or LICENSE or whatever without having to deal with every file in the standard distro profile.

        M::C will then generate the MANIFEST file (via MakeMaker) once all files have been generated. And of course, one could have a custom MANIFEST.SKIP in the local profile dir, as well. I can easily see a normal use-case where the local default profile dir would only have a couple of files in it, with everything else coming from the standard distro default profile.

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

In Section Meditations