First of all you should be clear about "config file" versus "data file". If another user installs the same module on another machine, will he have to adapt some of those values? If yes, it's config. If not, it's data.

Second point: Just because it's a module doesn't mean that by some magic it shouldn't have to have configuration or data files. There are good use cases for those. So I'm not quite sure what your question is. Yes, I have written code that depended on data files and configuration files. Yes, one can handle that.

If your module has a build system similar to most CPAN modules, File::ShareDir can help you locating the files.

The needs regarding configuration can vary drastically by application, but they have in common that for most needs CPAN already has a solution.

"Just because it's a module doesn't mean that by some magic it shouldn't have to have configuration or data files. There are good use cases for those. So I'm not quite sure what your question is."

You seem to have a pretty good handle on either possibility, actually. Also, you seem to have some insight into misunderstandings I might have made, would you mind addressing those for posterity? Note that I wasn't asking if one could handle that, but how.

"The needs regarding configuration can vary drastically by application, but they have in common that for most needs CPAN already has a solution."

Exactly why I'm here...or why most people are here: for some suggestions and advice on best practices used in certain circumstances. Having reflected upon my question in light of your observations, I'm thinking that this falls into the "data file" category. Occasionally certain values will need to be changed, but this would be on an application-wide basis, not on a user-by-user basis.

The module does not require a build process because it isn't intended for distribution, nor has it become generally useful enough to merit it, so perhaps File::SharDir is not the best solution.

Do you have any further suggestions, given my clarification?

In your case I'd probably just hardcode a path, like /usr/share/yourmodule/ and put the data file(s) there. Unless they are pretty small, in which case a __DATA__ section would be even easier. Then change your module to read them when it needs them.

That's the "how" if you don't follow the File::ShareDir route -- though personally I think that even simples modules should have a proper build/install system (via Module::Install or Module::Build), because it's easy to set up and easy to use.

Occasionally certain values will need to be changed, but this would be on an application-wide basis, not on a user-by-user basis.

This indicates that it's not a one-off script, but something that is developed and/or maintained over a longer period of time. I'd definitively go the Module::Install/Module::Build route for that, and use File::ShareDir to locate the data files. But your mileage my vary, of course.

Perl 6 - the future is here, just unevenly distributed

The module does not require a build process because it isn't intended for distribution, nor has it become generally useful enough to merit it, so perhaps File::SharDir is not the best solution.

File::ShareDir::ProjectDistDir then :)

As moritz already pointed out, if the information is static then what you have is a data file. In that event why not embed it into your module somehow?

If the end user is expected to modify the information somehow (DB name, DB host, user, password et. al.) then you should be using a configuration file. YAML, JSON, XML or just a good old fashioned text file with key value pairs is good. Another technique I've seen more than once is to create a file that looks a lot like a Perl module (in fact is) or plain Perl code to be read. Example:

package MyConfig; 

#
# For the record:  fixed the following 4 lines since my fingertips dec
+ided to do something 
# other than what my brain was telling them to.   s/my/our/ 
our $datahost="blah.foo.com";
our $datauser="user";
our $password="s3cr3t";
our $database="thedata";

1;
[download]

   |random handwaving here...
use MyConfig;

my $host=$MyConfig::datahost;
my $user=$MyConfig::datauser;
my $pass=$MyConfig::password;
my $database=$MyConfig::database;

   | now do something with it...
[download]

Personally for my own uses I use XML files and XML::Simple to load them.