Here is what I did in a vaguely similar situation.

I wrote a custom config module. This module had a search path that it knew to follow of places that it could find configuration information. When you called that module's import method, it looked at caller to figure out the module being loaded and then search for the appropriate configuration files. For a module named Foo::Bar, it would look for files named Bar.pc in that path. Each would be read into RAM, a package command would be inserted, and then eval called. When it was done it would then look through the import request, and would export them to the caller's package if they were loaded, plus would tell strict.pm that they were now OK. If they were not loaded I would die a horrible flaming death. To figure that out use the *foo{THING} syntax described in perlref. You'll need to require that all scalars must be defined.

The configuration path had a directory for good development defaults, a directory with as little as possible in it for overrides for production (presumably you'd want another for testing overrides), and a directory outside of source control for per developer overrides.

Together with a script to load the full configuration and then dump it in various formats, this should meet your needs.

Another solution that I've used is to build up a hash of different configurations for different situations where the configurations are built up from each other. Then require people to use special access functions for their configuration data. There are cases where this is more flexible than the other, and cases where the other is more flexible than this. On the whole I think I preferred the first approach - actually having variables exported into your namespace is a nice convenience touch.

But it seems that everyone has different desires for a configuration module. Which is one reason why there are so many configuration modules on CPAN, most of which are worse for my desires than raw Perl. Figure out what you want and pick a configuration solution that makes sense.

But, absolutely, you must settle on one. Even if it is a configuration solution that you dislike, a mediocre solution used consistently is better than several much better solutions competing with each other in the same code.

In reply to Re: Handling configuration for mutliple modules by tilly
in thread Handling configuration for multiple modules by jhourcle

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.