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.

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.

That could be a good example, in many senses: first of all, having an external configuration file where one can put weird paths for some needed external program; secondly, to get a clue about how actually check that there is some needed external software, and bail out if it's not available (which gives you dependency check as well).

Regarding hard dependencies and tests, you could make a test for the dependency. Something along the lines:

use Test::More tests => 1;
use English qw( -no_match_vars );

qx{ wget --version };
is($CHILD_ERROR, 0, 'wget is available');
[download]

3. Document? yes! Test? Also yes (but this view is merely based on personal taste; not any skills in testing).

I think that conveying the concept of update would restrict the scope of dragonchild's scripts. Perl::Install seems more in target IMHO.

Flavio
perl -ple'$_=reverse' <<<ti.xittelop@oivalf

Io ho capito... ma tu che hai detto?

but Perl:: is a new TLN

Que?

I don't like Perl::Install, it seems ambiguous. Example: Perl::Install::Java. Does this mean it installs Java? Perl::Install would then appear to be a base module for Perl::Install::Java.

How about Perl::Installation? It is a minor difference from Perl::Install; especially since there are so many Foo::Install modules but I do think it is a little clearer in what it is supposed to do.

As for dependencies Module::Build has calls for getting information from the user, it is called prompt().

Example from a Build.PL script I wrote, (Note: This is not a complete script).

my $code<<"END";
  ## Your custom installation code goes here
END;

use Module::Build;

my $class = Module::Build->subclass(
    class => 'Custom::Build',
    code  => $code,
);

my $builder = $class->new(
  # You need to add some of your stuff here!
)
if ($builder->args('default') or
    $builder->args('quick-install')) {

    my %notes = _get_default_settings();

    foreach (keys %notes) { $builder->notes( $_ => $notes{$_} ) }
}
else {
    my %notes = _get_prompt_settings();

    foreach (keys %notes) {
        $builder->notes( $_ => $builder->prompt(
            $notes{$_}{message}, $notes{$_}{default}
        ))
    }
}
$builder->create_build_script();
exit;
#################################################
sub _get_default_settings {
    warn "OS is $OSNAME\n";
    if ($OSNAME eq 'MSWin32') {
        return (
        config     => 'c:/EEBL/tmp',
        cgi        => 'c:/EEBL/tmp/cgi',
        tmpl       => 'c:/EEBL/tmp/tmpl',
        url        => '/EEBL',
        )
    }
    else {
        return (
            config => '/var/www/eebl',
            cgi    => '/var/www/eebl/cgi',
            tmpl   => '/var/www/eebl/tmpl',
            url    => '/EEBL',
        )
    };
};
#################################################
sub _get_prompt_settings {

    my %settings = _get_default_settings;

    return (
        config => {
            message => 'Where will the config.txt file be installed?',
            default => $settings{config},
        },
        cgi    => {
            message => 'Where will the cgi files be installed?',
            default => $settings{cgi},
        },
        tmpl   => {
            message => 'Where will the template files be installed?',
            default => $settings{tmpl},
        },
        url    => {
            message => 'What is the root url for the web site?',
            default => $settings{url},
        },
    );
}
[download]

Hope this gets your started.

Right now, I'm leaning towards Perl::Install, but Perl:: is a new TLN and I'm a bit leery of taking that. Where else would it go?

How about Admin? Pehaps Admin::Install or Admin::Installation?

Of course, once there's an Admin at the top level, it's going to attract all sorts of system administration tools...