I just wanted to jump in, though the answers are already in the thread I think.

You could just define a hash at the top of the program, or a __DATA__ section at the bottom, or put settings into a separate module (like Site.pm). I tried those but don't recommend them for setting data values. Exported functions tend to crawl into Site.pm, and only you really know how to edit it. It requires a lot of discipline to use a separate module for your configuration, and it just confuses everyone else.

To make software bilingual I've often used a hand-rolled hash which just slurps data in from a two-column text file (skipping comments, and delimited by one or more spaces or tabs). This worked very well, in particular for storing UI error messages and bits of Japanese strings (I'd keep Japanese SJIS-encoded strings in the text file and call them up using an English hash key).

But for what you usually think of as settings I've had best luck with INI style files, sorry don't remember if it was AppConfig or Config::IniFiles. Lots of people can figure out how to edit them or already know how, and IIRC you can write back to the file too.

As it happens IIRC (I could be mistaken) the Config::IniFiles module also lets you specify defaults at the top that can be overwritten below. Anyway, I have had good experiences with it, and have used it to roll my own controller for the htdig search engine, to store information on 60 databases and what sites to spider, what languages to let users search in, etc. It is also very nice for small programs, and I've used it with a WxPerl GUI app which also worked quite well. It's been a while but IIRC I kept one copy of the INI file for defaults, and then let the user set defaults in the GUI which got written back to the INI file when they clicked the Save button. This was great.

Now I am using Catalyst and YAML. Even though YAML sounds easy it took me a while to understand mostly what is going on, and even so I have had to use the command line simulator sometimes. But I think people could figure that out too. It seems that YAML is great for catalyst because by nesting labels you can easily overwrite defaults in several different modules, due to the way it is unrolled on top of the app's shared data structure. So while I have not had long experience with it, it seems that YAML is better for storing small data structures too in your config file, so you get more out of it after you get used to it.

Much as XML is hyped, I've hated editing XML every time I had to. If humans are going to touch it I would stay away from XML, and go to YAML instead. As it happens, you are also human and it is refreshing to be able to change a config file instead of having to dive into a module and worrying about breaking things, etc.

Anyway, you may like to experiment a bit but I'd recommend INI or better yet, YAML.

Oh and here's that code I used for error messages, FWIW. (click the "download" link to view full-width lines). It was useful for making email response templates (munged with HTML::Template) and pull-down menu data like a list of prefectures. I also used it to simulate an apache-style config file for server settings, since you can put in comments. The note that SJIS can break is only true if you use a comma separated list in Japanese and don't use Japanese regex module. Free for you to use, it is quick but maybe better to first learn a little YAML before you miss out...!

Good luck, Matt

sub loadtextconfig {

        # Read a text-based config file into a single-level hash, die 
+on disk error
        # Usage: loadtextconfig(\%myhash, $myfilename);
        # Note: SJIS CAN BREAK/bakemoji e.g. a comma separated list of
+ prefectures
        # Copyright 2001-2004 (c) Matt Rosin

        my ($href,$f)   = @_;
        my ($i,$j)              = (0,0);

        open(W,$f) || die  "Content-type: text/html\n\n ERROR: Could n
+ot open $f $!";
        while (<W>) {
                next if /^#/;                           # ignore comme
+nted lines
                $_ =~ s/\r|\n//g;                       # remove endin
+g carriage return and/or ne
wline
                s/^\s+//;                               # remove leadi
+ng whitespace
                s/\s+$//g;                              # remove trail
+ing whitespace
                next unless length;                     # skip blank l
+ines

                ($i,$j) = split(/\t/,$_,2);             # $j holds res
+t of line
                $j = "" unless (defined $j);
                $j =~ s/^\s+//;                         # remove leadi
+ng whitespace
                $href->{$i} = $j;
        }
        close(W);

        # print "loadtextconfig $f: <PRE>\n" . Dumper($href) . "</PRE>
+\n";
}
[download]