Please don't think I am "having a go", because I am not, but I don't get this. And I don't get it at multiple levels.

1. You have a working solution. You cannot find an off-the-shelf CPAN solution. But you are looking to replace your working solution with someone else's (external to your organisation) code?

   The point of CPAN, and code reuse in general, is to leverage existing solutions. You have an existing solution! Why replace it?

   I've seen the claim made that you avoid maintenance by using CPAN, because someone else maintains them, but that makes no sense. Maintenance is only required if something breaks; or changes.

   • In the former case, if the code is in-house, if no one changes it, nothing will break.
   • Unless something changes in the calling code, in which case it would break the CPAN code as well.

   With the code in house, you can make the changes easily and quickly.

   With a CPAN module you would have to

   1. negotiate with a third party to agree a change is needed;
   2. agree what that change should be;
   3. await their pleasure in making and testing and shipping that change.

   And you still have to test their changes are compatible with your code-base and don't break anything else.

   And you create a dependency, and subject your code to the vulnerability that the author may change his module in a way that breaks your code in some future release.

   Where is the saving, ROI, code-reuse that comes from discarding your in-house working solution, for a speculative, third party equivalent?

2. This "config file" presumably lives in the same place as the rest of your code-base?

   But,

   1. use boils down to require.
   2. require boils down to do.
   3. do boils down to eval.

   In other words, every piece of Perl code you run, gets eval'd.

   Why is is good enough for the rest of your code-base, and not for this piffling little config file?

   On that basis, you will need to write your own Perl Interpreter, (in some language other than Perl!), so that you can untaint the rest of your code-base?

3. If you really do have to untaint the contents of this config file, wouldn't it be simpler and quicker to change the format of the file so that it didn't mimic executable code?

   You could then use one of the dozens of existing config modules that doesn't use eval.