Also consider if you need to have (two) different configuration files at the same time.

I would ditch or disable the Perl::Critic rule that prohibits a direct require.

PerlCritic rules are sometimes just good suggestions, and often the experienced programmer will know better.

$ perlcritic --verbose 11 foo.pl
"require" statement with library name as string at line 6, near 'requi
+re '/tmp/config.pl';'.
  Modules::RequireBarewordIncludes (Severity: 5)
    When including another module (or library) via the `require' or `u
+se'
    statements, it is best to identify the module (or library) using a
    bareword rather than an explicit path. This is because paths are u
+sually
    not portable from one machine to another. Also, Perl automatically
    assumes that the filename ends in '.pm' when the library is expres
+sed as
    a bareword. So as a side-effect, this Policy encourages people to 
+write
    '*.pm' modules instead of the old-school '*.pl' libraries.

        use 'My/Perl/Module.pm';  #not ok
        use My::Perl::Module;     #ok
[download]

So this means the rule exists because its author(s) were worried that people are writing Perl-4-style libraries. Since in this case you know better and config.pl is not a library, you are free to overrule PerlCritic:

require '/tmp/config.pl'; ## no critic (RequireBarewordIncludes)
[download]

Of course there are other ways to "fix" the issue, e.g. to use do or even eval (but require is fine). Also, you could just turn config.pl into MyConfig.pm and make things easier that way too.

Why use Perl::Critic if you don't want to follow its advice?

Using require to load a configuration file is a bad idea. For one thing it will silently fail to load the file into more than one package. From the docs for require:

Otherwise, require demands that a library file be included if it hasn't already been included. ... Note that the file will not be included twice under the same specified name.

$ cat conf.pl
#!/usr/bin/perl
use strict;
use warnings;

our %conf = (
  foo => 'bar',
  baz => 'quux'
);

__END__
[download]

$ cat ONE.pm 
package ONE;

use strict; use warnings;

sub one {
  our %conf;
  require 'conf.pl';
  return $conf{'foo'};
}
1;
[download]

$ cat TWO.pm 
package TWO;

use strict; use warnings;

sub two {
  our %conf;
  require 'conf.pl';
  return $conf{'baz'};
}
1;
[download]

$ cat 1137798.pl
#!/usr/bin/perl -w
use strict;

use ONE;
use TWO;

print ONE::one, "\n";
print TWO::two, "\n";

__END__
[download]

Output:

$ perl 1137798.pl
bar
Use of uninitialized value in print at 1137798.pl line 8.
[download]

Change the require calls to do as somebody else noted and you can then import your config file into more than one package, which is useful.

$ cat ONE.pm 
package ONE;

use strict; use warnings;

sub one {
  our %conf;
  #require 'conf.pl';
  do 'conf.pl';
  return $conf{'foo'};
}
1;
[download]

$ cat TWO.pm
package TWO;

use strict; use warnings;

sub two {
  our %conf;
  #require 'conf.pl';
  do 'conf.pl';
  return $conf{'baz'};
}
1;
[download]

$ perl 1137798.pl
bar
quux
[download]

So use do, or better yet, just use Config::Tiny, which exists to solve your problem.

$ cat conf.ini 
[path]
foo=bar
some=other
[url]
baz=quux
less=more
[download]

$ cat 1137798-2.pl
#!/usr/bin/perl -w
use strict;
use Config::Tiny;

my $conf = Config::Tiny->read( 'conf.ini' );

print $conf->{path}->{foo}, "\n";
print $conf->{url}->{baz}, "\n";

__END__
[download]

Output:

$ perl 1137798-2.pl
bar
quux
[download]

Now what's overkill about that?

require '/path/to/config.pl'; ## no critic (Rule name)
[download]

Even you can use do() to include .pl file, as below.

use strict;
use warnings;
use Data::Dumper;

our $config = do '/pathto/config.pl';

print $config->{'foo'};
[download]

Why using unlimited executable code in a config file is a bad idea: Re^2: conf file in Perl syntax.

Use a non-executable configuration, as 1nickt++ explained. If you don't like Config::Tiny, or if INI files are too simple for your configuration, consider using JSON (e.g. using JSON::XS), XML (with the help of e.g. XML::LibXML), or YAML.

All of these formats contain no executable code.

Update (2015-08-09): YAML can contain executable code. Depending on how you configure the YAML reader, parts of the configuration file may be executed. So don't use YAML until you know how to prevent the YAML reader from executing code from the YAML file.

Alexander