I think that it is not a modules task to know on which machine it is run. There are Modules in the perl core which do different things depending on the operation system they are running on for the sake of portability, e.g. File::Spec. Instead in your case I'd place the burden on the shoulders of the module user, i.e. the code which uses the module. To set something in the module's namespace, write a import subroutine which does just that. You decide whether that variable is visible (and/or changeable) from the outside (our, or package global), or if it is a private variable to the module which can be set only once in the import routine.

package Foo;

my $dir; # could be 'our' to be visible from outside

# portablitity... far from complete
if ($^O eq 'MSWin32') {
    $dir = 'C:\Users';
} else {
    $dir = '/home';
}

sub import {
    my $package = shift; # just the package name
    if (@_) {
        if (@_ % 2) {
            die "odd number of parameters in ".__PACKAGE__"::import(),
+ aborted";
        }
        my %args = @_;
        if ($args{dir}) {
            $dir = $args{dir};
        }
    }
}
... # more module code
1;
[download]

Code using this module would say use Foo dir => '/tmp_mnt/home' if it was running, say, on SunOS-4.1.3 and the home directories were mounted via NIS, NFS and automounter. I digress... but you get the picture ;-)

Since use statements lead to compiling and executing the used module which the current script is parsed, any intialization of arguments to e.g. use Foo dir => $somedir must happen before use Foo is called, which means that this code must be IMMEDIATE (in forth terms). This is done wrapping the initializing code into a BEGIN block prior to use Foo. The contents of this block will be parsed and executed immediately.

your question is a little smoky, for me.

Config::Any and Config::General and JSON::MaybeXS are valid options to have a separate configuration.

Also YAML can be used to have separate configuration.

But perhaps it is better to specify to us what makes machine X different from machine A. Many modules has builtin for configuration using some exported (or anyway accessible using the full package qualified name) variable. This can sounds weird to someone but is, imhe, a frequent thing.

Many others use effective %ENV vars to change their behaviour; this is vary basic but valid too.

L*