Programmer's notebook: config files

[Irving Kimura]

I'm relatively new to Perl, and I'm still learning the basic patterns
of good Perl programming. Here's one I'm having to deal with right
now: config files.

Often programs/scripts can have so many system-dependent options
that it is not practical for them to be specified command-line
flags. In these cases, a common strategy is to use configuration
files that the program reads at start-up. What's your favorite
way to handle system-dependent constants?

One straightforward approach is to define a simple syntax for the
configuration file (e.g. separate lines consisting of VAR=val pairs,
plus comments and blank lines), and having one's program parse this
file to get the configuration parameters to use.

But as I learn more about Perl, I see that another possibility is
to have a file (e.g. My_Module/Constants.pm) with format such as
this:

package My_Module::Constants;
use constant VAR1 => var1;
use constant VAR2 => var2;
# etc.

and then put the line

use My_Module::Constants;

at the beginning of every script that needs these configuration
variables. Then, the rest of the code can use these configuration
variables like this: my $foobar = My_Module::Constants::VAR1.
One advantage this approach has over the previous one is that it
gets perl to parse the config file for us.

This last technique looks to me like the way to go, at least for
programs that are expected to pay attention to no more than one
configuration file (as opposed to those that must deal with end-user
customizations), but I'm still too green with Perl, and I wonder
what pitfalls this approach may have, and whether there is a better
way to accomplish this task in Perl (yeah, I know about TMTOWTDI).

Thanks for your comments.

Irv

 

[gnari]

[snipped discussion about config files]

...
But as I learn more about Perl, I see that another possibility is
to have a file (e.g. My_Module/Constants.pm) with format such as
this:
...
and then put the line

use My_Module::Constants;

at the beginning of every script that needs these configuration
variables. Then, the rest of the code can use these configuration
variables like this: my $foobar = My_Module::Constants::VAR1.
One advantage this approach has over the previous one is that it
gets perl to parse the config file for us.

it all depends, of course.
it depends on whether the config is changed/set at install time
or frequently.
it depends on whether the config should be user-editable
it depends on whether the scripts using it are all in one location,
or if they are scattered all over, and maybe run by different users.

you have a few possibilities:
local configuration file, parsed by program/module
global configuration file (/etc or something)
require conf.pl
use MyModule::Conf

the module is pleasant if it needs to be used by various scripts,
say cgi, admin and cron scripts, all run under different environments,
and by different users. then there is no problem finding the config,
the 'use' command finds it for you.
the downside is that it is slightly more trouble if you need to edit it.
in that case you might have the module contain the location of the
editable conffile.

gnari

 

[Tad McClellan]

use constant VAR1 => var1;

^^^
^^^

That is a strange choice of name for something that is not variable.

 

[Anno Siegel]

I'm relatively new to Perl, and I'm still learning the basic patterns
of good Perl programming. Here's one I'm having to deal with right
now: config files.

Often programs/scripts can have so many system-dependent options
that it is not practical for them to be specified command-line
flags. In these cases, a common strategy is to use configuration
files that the program reads at start-up. What's your favorite
way to handle system-dependent constants?

One straightforward approach is to define a simple syntax for the
configuration file (e.g. separate lines consisting of VAR=val pairs,
plus comments and blank lines), and having one's program parse this
file to get the configuration parameters to use.

There are a few modules on CPAN that do that. A colleague of mine
has been using Config::IniFiles to configure a print server. It
has supported 2500+ lines of configuration data with lots of changes
over the last few years, but there are other modules.

But as I learn more about Perl, I see that another possibility is
to have a file (e.g. My_Module/Constants.pm) with format such as
this:

package My_Module::Constants;
use constant VAR1 => var1;
use constant VAR2 => var2;
# etc.

and then put the line

use My_Module::Constants;

at the beginning of every script that needs these configuration
variables. Then, the rest of the code can use these configuration
variables like this: my $foobar = My_Module::Constants::VAR1.
One advantage this approach has over the previous one is that it
gets perl to parse the config file for us.

[advantages of this approach]

That's always an alternative. There are also downsides.

Maintainers of the configuration must understand some Perl to do their
job. They also must be trusted since they can make the final job do
*anything*.

It also blurs the distinction between code and data. There will always
be a temptation to put a little routine or two in the configuration
file because it's convenient. If you don't exercise strict discipline,
you end up with stuff in the configuration that doesn't belong there.

Anno

 

[Irving Kimura]

Maintainers of the configuration [...]
must be trusted since they can make the final job do
*anything*.

I see. But wouldn't this concern apply to any easily editable
script?

It also blurs the distinction between code and data. There will always
be a temptation to put a little routine or two in the configuration
file because it's convenient. If you don't exercise strict discipline,
you end up with stuff in the configuration that doesn't belong there.

Good point.

This is very useful feedback. Thank you very much.

Irv

 

[Anno Siegel]

In <[email protected]>

Maintainers of the configuration [...]
must be trusted since they can make the final job do
*anything*.

I see. But wouldn't this concern apply to any easily editable
script?

Yes, but unlike a config file, normal scripts don't *have* to be easily
editable.

Anno

 

[bill]

Maintainers of the configuration [...]
must be trusted since they can make the final job do
*anything*.

I see. But wouldn't this concern apply to any easily editable
script?

Just run the rest of your script through an obfuscator.

bill