Re: Config files in CPAN modules?

Lots of software looks at several places for configfiles. Ie. a systemwide config and a user-specific config. Usually the user-specific config can override the systemwide config (exception is security-type options for instance). User-specific configs usually live in a users home directory (on UNIX as .<appname>rc files, like .cvsrc ).

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.

Comment on Re: Config files in CPAN modules?

Replies are listed 'Best First'.
Re^2: Config files in CPAN modules? by doom (Deacon) on Jul 21, 2006 at 20:44 UTC
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?	[reply]
Re^3: Config files in CPAN modules? by mr_mischief (Monsignor) on Jul 21, 2006 at 22:22 UTC
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	[reply]
Re^2: Config files in CPAN modules? by sciurius (Beadle) on Jul 21, 2006 at 20:39 UTC
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.	[reply]