Personally, I find that any script of sufficient complexity better lives as a module and a "wrapper script" anyway. Most of the time, this process starts once I have to debug the script and have to write tests against specific functionalities of the script. If you find your script is larger than (say) 100 lines, excluding documentation and switch parsing, I think wrapping the script into a module and calling App::BuildPerl::do_it() from the calling script is a sane approach and allows for later utilization/customization of the "application" by another calling script.

I agree completely: moving the guts of a script to a module facilitates testing a lot. Consider that you can use the perl debugger to trace through a test file that makes calls to do_it(), but any place you shell out to an external script you'll run into a hard wall that the debugger can't step into.

And of course, if you can break out the functionality of that do_it into multiple subs, it becomes possible to write finer-grain tests that examine each of the subs.

One thing though: I've gradually come to the conclusion that it should be the job of the script to unpack any command-line options (from Getopt::Std or whatever) and translate them into options used by the module. Don't write subs that work by having the options hash passed in from the script: then you get stuck being unable to change the external interface without re-writing internal code.

Of course, if you'd rather not re-engineer the code at all for the first release, nothing stops you from attaching your scripts to a dummy pm that to begin with contains nothing but pod for the scripts.

In reply to Re^2: CPANization of a script for building Perl by doom
in thread CPANization of a script for building Perl by dragonchild

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.