in reply to Single file oriented for different usage

If using a single file is causing you headaches, then don't use a single file.

In my projects, we solve that problem by having two config files. One is the main one, one has $USER-specific overrides. So, when you run the app, the main config file is loaded, then, if one exists, the $USER-specific one is loaded and overrides anything it needs to override.

My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
  • Comment on Re: Single file oriented for different usage

Replies are listed 'Best First'.
Re^2: Single file oriented for different usage
by arbingersys (Pilgrim) on Feb 26, 2008 at 17:25 UTC

    Thanks. That would certainly work in the case where the parameters are established, and they won't change much. (Like if I ever near stable, non-beta releases.) But while it's under active development and I still might be experimenting, I can't guarantee that parameters, parameter names, etc, won't shift around, be removed, or altered in a way that would break a user config file. Any suggestions in this case?

    A blog among millions.
[reply]
      You couldn't guarantee that anyways, even in prod. Just look at how often parameter names change in Oracle, let alone MySQL or Apache. Just get it done. :-)
      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]

        Right. So multiple copies of Config.pm then... ?

        A blog among millions.
[reply]

In Section Seekers of Perl Wisdom