Re: CPANization of a script for building Perl

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.

External/alien dependencies are hard, but in your case, you could use File::Fetch as a prerequisite, which is what CPANPLUS uses to retrieve files specified via URIs; this is still slated to become core with Perl 5.10. I would specify/optionally require File::Fetch and in case that fails blindly fall back to `wget -o $target "$url"`. You could verify the wget functionality through a test though, or, if you're using Module::Install as your build mechanism, it has requires_external_bin().

Of course, in all cases, it's better to release something than fretting over how to best specify the finer details to make the script work everywhere.

Comment on Re: CPANization of a script for building Perl Select or Download Code

Replies are listed 'Best First'.
Re^2: CPANization of a script for building Perl by doom (Deacon) on Dec 16, 2007 at 22:13 UTC
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.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: CPANization of a script for building Perl
by doom (Deacon) on Dec 16, 2007 at 22:13 UTC

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.

[reply]
[d/l]
[select]