So what's a good way to deal with this?

One way I've solved this for some modules for general use that I've authored for my job is to use XML::Simple to store my configs. If I have a program that is invoking a module that needs to get to a config file named "foo.pl" I simply create a file in the directory the script lives in called "foo.xml" and put the configuration information in there. For instance I have some database access modules that I use a lot and I store the information as such:

<disco_database>
     <host>database-host.foo.com</host>
     <dbname>disco</dbname>
     <user>disco</dbname>
     <password>duck</password>
</disco_database>
[download]

package my_package;
use Class::DBI::Loader; 
use XML::Simple;
     | much handwaving...
sub new { 
     | more handwaving...
     my $config = new XMLIn();
     $self->{loader} = 
       Class::DBI::Loader -> new (
        dsn => sprintf("dbi:%s:dbname=%s;host=%s",
               $config->{disco_database}->{driver},
               $config->{disco_database]->{dbname},
               $config->{disco_database}->{host}),
        user=>$config->{disco_database}->{user},
        password=>$config->{disco_database}->{password}
         | and so forth...
[download]

In other cases (and actually, the project I call "disco" is a good example of this) I put a config file that is central for that module. If I ever have to override it I make that a potential parameter for instantiating the module. For instance:

| blah blah...
use IBM::Disco::HostEntry;

|
}
| blah
|
|
my $he = IBM::Disco::HostEntry->new{ config_file => 
                 qq(/path/to/file) );
|
[download]

Allow the user to sub-class your module and specify there configuration there (either as a reference to a file or the actual configuration

package My::Whatever;
use base Whatever;

sub config_file { "/usr/home/whatever" };
[download]

Seems like this gives the most power to everyone involved, even means that i could have several configurations and easy access to each.

Phil

My advice would be to consider using a 2 configfile type of approach, make it work in all three situations ( system-config + user-config, system-config + no user-config, no system-config + user-config ) and document what overrides what.

This suggestion (provide both a system-wide and user-specific config) is very sensible and helps alleviate the central problem, but I don't think it eliminates it. What should the installer do when confronted with an existing system-wide configuration file? Overwriting it is harmless only if all customization has been confined to the user-specific files. Most likely, you're stuck with doing something like silently creating a "config.new" file, and leaving "config" alone. For extra-credit, you could examine the existing config file to see if it differs from the default (compare MD5 hashes?) and overwrite if no customization has been done. And if you want to go above and beyond, you could try to merge your changes into the existing file.

Note: asking the user about this in the middle of an installation is to be avoided on penalty of death. Think about someone using CPANPLUS to install a module with a cascading series of dependencies involving dozens of modules. What if every other package wanted to politely ask a question about something?

I like the opposite -- save the original as 'config.orig' or 'config.old', or perhaps 'config.2006-07-21' for example. Then, save the new one as 'config'. It's pretty common, and it gives me a point of reference when I go to customize the new one.

What's really best, though, is when a package recognizes an obsolete config file and saves a 'config.old', a 'config.defaults', and a 'config' that has all the options from 'config.old' updated to match the new format and adds any settings from 'config.defaults' that used to be hardcoded and now aren't. Preferably, the new config file will be set up with things specified as much like the old version worked even if the default behaviors have changed, and with notes in the config file's comments stating what's changed and why. I can't name a CPAN module that does this currently, but I've used a few server and desktop applications that do this. That's one of the biggest things I like about the CMS I recommend for my clients, actually. When they upgrade it (or hopefully when they pay me to upgrade it), the upgrade is almost seamless.


Christopher E. Stith

I think it's important to adhere to the system philosophy of placing config files. Some systems use /etc/, some systems use /usr/share, some systems use C:\USER_SETTINGS. Unfortunately, there is no CPAN module that makes this transparent.

Hi,

Normally what I do is asking the user to provide the configuration, could be the config itself, or the path to the configuration file:

MyModule->new({ config_file => 'file.conf'}); # or
MyModule->new({ config => \%Config });        # or
MyModule->load_config($file);                 # etc...
[download]

This way it's up to the users script to decide which method he uses to provide the modules with the configuration settings.

Or going for well known places where the config files should be (linux -> /etc or /usr/local/etc) could be with subdir for the application itself or so; or the other way is to create a hierarchy for the application itself:

MyApp
 |
 +-- bin/
 +-- etc/
 +-- lib/
 +-- docs/
[download]

But the most important thing of all is to DOCUMENT it. So that the user know how he must do instead of figuring it out. ;-)

Regards,

There is no reason to install a default config file.

• Define a config format that begins with "1;\n__END__\n", and continues with whatever sort of config data you like.
• Have your users put "myapp.conf" anywhere in @INC. Optionally recognize a special environment var (say, MYAPP_HOME) to temporarily push onto @INC, just in case they don't feel like fooling around with PERL5LIB :)
• In your code:

  {
  local @INC = @INC;
  unshift @INC, $ENV{MYAPP_HOME} if defined $ENV{MYAPP_HOME};
  require 'myapp.conf';
  }
  open my $conf, '<', $INC{'myapp.conf'} or die 'Flaming death';
  1 while <$conf> ne "__END__\n";
  enjoy($conf);
  [download]
  

It installs a basic set of config data in CPAN/Config.pm, which can be overridden by data stored by the user in .cpan (which CPAN.pm silently creates and manages).

Whether this is sufficiently cross-platform enough for you I don't know, but it's certainly an alternative.

I'd be tempted to suggest Config::Std for config files, except for the fact that it doesn't handle a dynamic choice of config file well (you can always eval a 'use', though).