Did you ever look at the Config::* namespace on CPAN? Even if you ignore the 500+ hits that don't start with Config::, that still leaves 170 to wade through. Whilst there are undoubtedly one or two excellent modules amongst that number, there is also an aweful lot of dross.

Pick the wrong one, and you can be letting yourself in for a great deal more grief than having to clean up a bug or two in your own code.

Settle upon your own code, make it into a module for your own internal use and it can evolve to meet the requirements of new applications or extensions and new requirements to existing ones, as they arrive.

Settle upon the wrong CPAN solution, even a good one for your initial requirements and down the line you are faced with the problem of pursuading the author that your new requirement fits with the nature of his module; or backing it out from existing applications; or maintaining multiple Config modules going forward.

Many algorithms and requirements are clearly defined and universal enough that one or two good CPAN implementations are sufficient to encompass them.

Others, like configuration--and a favorite bugbear of mine, commmand line argument processing--are sufficiently application specific, or subject to variation according to personal and/or corporate preference, that having YACM for each variation means that the namespace is over subscribed with a confusing and time consuming array of possibilities. Some of which may be great modules, but many of which are ill thought through, over engineered, or just down right shoddy.

Yes. I have looked. And I asked in the CB and got good answers. As I implied in Re^3: Converting a Flat-File to a Hash, half an hour's research (including consulting the CB) got me a few CPAN modules to look at (about the same list bobf suggested), one of which solved the problem for me.

To an extent the problem is similar to the command line problem, and the answer is similar: go with the prior art. It may not be an exact fit for your initial specification, but over time there are likely to be fewer surprises by adopting standard technique. Certinally there is less learning Yet Another Configuration Technique required if you adopt one technique and use it wherever possible.

Context alters most things of course and there are no hard and fast rules in providing configuration information. It's a whole lot closer to the gray areas than trying to parse HTML with regexen for example. However there is still great virtue in taking a look at the prior art, even if just as a way of sorting out edge cases earlier rather than later and for gaining insight into where your own code may need to evolve. Looking at CPAN to find out how stuff doesn't work and what it doesn't do can be just as rewarding as finding the module that does exactly what you need.

---

DWIM is Perl's answer to Gödel

• half an hour's research

  Less than half an hour to whittle 170 down to 1? You must be a fast reader :)

• (including consulting the CB)

  Perhaps the OP doesn't use the CB, and his post is his attempt to do the equivalent of your CB enquiry. To get a few suggestions as a starting point. Had you made your initial enquiry in the form of a post rather than in the CB, he might have seen the replies that you received and not needed to post.

  It's quite likely that the less than perfect example code he posted was more a reaction to the standard "What have you tried?" boilerplate that tends to get summarily attached to any OP without code.

• got me a few CPAN modules to look at (about the same list bobf suggested),

  That's one of the major problems that arises when this topic, (the Getopts::* one also), periodically crop up: There is never anything like a consensus. It is even a rare occurrence when any individual post simply recommends one module--from memory, they nearly always offer some subset of the CPAN list, but rarely offer any indication of:

  1. Why that particular subset.
  2. What criteria should be used to decide between that subset.
  3. Either positive or negative comment upon particular modules.

  The latter I understand, as even the mildest critique of a module here, tends to lead to mortally aggrieved authors, and instant 'friends' leaping out otf the woodwork to their defense.

  However, you'd think that one or two of the existing, higher quality modules would have sufficient merit to garner some positive comment beyond "I used it. It seemed to work."?

• one of which solved the problem for me.

  I notice that you refrained from telling us which one, much less why.

• To an extent the problem is similar to the command line problem, and the answer is similar: go with the prior art.

  Same problem. Which prior art? And why?

  For the GetOpt::* problem, there are Std; Short; Long; Mixed; OO; Simple; Fancy; Compact; Casual; Declare; Easy; Fancy; Helpful; Lucid; Plus; Tiny; Tabular; and WonderBra. And that's far from exhaustive. Some of those are by the same author!

  Which to choose? And why?

  Prior art with this level of diversity strongly indicates that:

  1. there is no consensus on the right way;
  2. there is no safe bet, as no one module has enlisted enough support to be guaranteed to be well exercised, tested and debugged.
  3. That maybe, the scope for variation in requirements, approaches and implementations simply defy the provision of a single solution.

     That maybe you'll have to write your own to get what you need, without getting a whole bunch of stuff that you don't need; or worse absolutely mustn't have.

• Certinally there is less learning Yet Another Configuration Technique required if you adopt one technique and use it wherever possible.

  For example. Most, if not all the GetOpts modules on CPAN adhere to some variation or other of the unix-style command line interface. And the thing to note is the number of variations.

  From the initial form, to the current practice, these have been extended again and again without any real consensus having been reached. What's more, the latest advisory guidelines for best practice, through the design-by-wide-spread-and-loose-knit-committee have arrived at a place where the result is that the interfaces to anything with more than trivial requirements is so complex and verbose that it requires two or more screenfuls of help; and additional options to allow the command line parameters to be read from a file--aconfiguration file! For want of a better name.

  The format of these files is defined on a case by case basis; is often scantly documented, if at all. Even where there are common threads in the formatting across applications, each has extended those "conventions", in competing and different ways, such that the presence of the similarities is actually a hindrance rather than a help. They can lead to the feeling that you know what the conventions are when in fact there are no real conventions, leading to immense frustration and wasted time figuring out why what works in one place does not work in another.

  Unix has a loose convention that program configuration file names start with a '.'. There are a (widely variable) list of well-known places where these are looked for. And a widely varying order of precedence given to the places on that list if more than one is found. And variability in whether further searching is done once the first is found.

  This wide variability (to me) suggests two things:

  1. That prior art in these areas has yet to arrive at a consensus.
  2. That maybe, the original direction taken to solving the problems of command line interfaces all those years ago was the wrong direction.

     And that no amount of adaption, enhancement and evolution of that basic direction can solve it's problems.

  Maybe, it's time for a new direction.

A few of the things that I want to see in a configuration module.

• I want the command line options and the configuration files to work in concert with one another.
• I want the configuration file to remember the last set of options I used for each application.

  Effectively a command line history on a per application basis. Command line processor histories are no substitute for infrequently used applications.

• I want simple access to the default settings for command line options.

  The command typed without options should show me what defaults will be used and offer me the chance to enter any changes or missing options without recourse to re-typing.

• I want those defaults to adapt, whether intelligently, or upon user instruction.

  If I use the same, non-default setting for a particular option 3 times on the trot, that becomes the default for that option.

  Or, if an option os post-fixed with some character (say '!'), that setting becomes the default.

• I want quick access to usage as I am typing the command line without discarding what I have typed so far.

  If the last character on the command line is a '?' when I hit enter, the usage for that particular option is displayed and then the command line, minus the '?' is restored ready for me to continue typing.

• I want to be prompted for mandatory options that I have omitted and for which there is no (safe) default.
• I'd like for some module configuration to be super-application.

  Hard to explain, but (for example), I might add an option: -Data::Dumper::purity=1, and that would get fed through to the appropriate module.

  And there might be a configuration file for the Data::Dumper module that allows me to specify my preferred configuration such that they become the default for all my uses of it unless overridden by a application specific configuration option.

And I've hardly scratched the surface.

Windows has the registry. It would be nice if this was transparently used on that platform instead of the .config files on other platforms, thereby addressing the biggest, but least considered, source of cross-platform incompatibility for command line applications.

Wouldn't it be nice if the same mechanisms could transparently present a cross-platform compatible GUI interface to the options and configuration upon request?

Sometimes, the "Use CPAN" missive is simply inapplicable. And sometimes it is time to look at the status quo, collectively and without reproach, and consider whether it is time to break with prior art and consider the options [sic] for a new approach.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.