I use two approaches for this.

Either, a module documents and exports an explicit initialization routine:

package Foo;
my $dbh;

sub init_foo {
    my( %script_config )= @_;
    # Read config file
    ...
    # Connect to database
    $dbh ||= $config{ dbh } || connect_to_foo_database( %script_config
+ );
    # Set up cache
    ...
};
[download]

Alternatively, I construct these things when they are first needed:

sub frobnicate {
    my( $self, %options )= @_;
    $options{ dbh } ||= $self->get_dbh;
    ...
};

sub get_dbh {
    my( $self )= @_;
    $self->{ dbh } ||= do {
        DBI->connect( $self->{dbi_parameters} );
    };
};
[download]

The approach is more explicit in the sense that things fail early, but it needs the explicit call by the person writing the script.

The other approach is more implicit in the sense that things only get initialized once they are needed.

I don't like the implicit magic of having a special name for the module which is called to configure things.

If I had to implement such magic, I would have something like this:

package Module::MagicInit;
use strict;

my @init_queue;
sub register_init {
    push @init_queue, [ (caller(1))[2], @_ ];
};

sub init {
    for my $task (@init_queue) {
        my( $package, $callback, @args )= @$task;
        $callback->( @args ) or die "Init failed for $package.";
    };
};
[download]

... and then use that like so:

package Foo;
use Module::MagicInit;

register_init( \&my_init, 'Hello', 'World' );

sub my_init {
    my( $greeting, $name )= @_;
    print "$greeting, $name\n";
};

1;
[download]

#!perl -w
use strict;
use Module::MagicInit;

...

Module::MagicInit::init();
[download]

Thanks for your reply.

Yes, the possible "magic" implementation I had in my head is close to yours.

As for the implicit approach, I really like this one, but there's a caveat. I would like the init code to fail early and loudly so that deficient and/or misconfigured installation does not go into production.

Devel::Init

Update: For those who (understandably) don't realize that there really is pertinent information for this thread available if you follow the above link (slightly paraphrased):

The documentation lays out best practices for ensuring that initialization will always be done before it is needed and not before it is possible, even when complex interdependencies between initialization steps exist.

Devel::Init allows module authors to declare what initialization steps are required and then allows each situation to very easily drive which types of initializations should be run when (and which types should not be run until they are actually needed).

And Devel::Init makes it easy to write your initialization code so that a circular dependency will be detected and be reported in an informative way.