The remedy is to install said module. That was said.

The "religious argument" is whether to install it in a way which will affect system perl or install it in a separate "container" (i.e. perlbrew or any other perl-parallel equivalent) so that installed module will have no effect on the system which relies on its own perl+modules (also means specific versions). It's not a religious argument it is common sense, I think (and I would follow that).

For example, if the system relies on specific module version and one installs the newest version then system may break. In this specific case, on the surface there is no problem because said module is not installed already, meaning that system does not need it (yet).

Installing it will seemingly create no problem, but what if pre-requisite modules are also installed by means of the first innocent installation and overwrite system-wide modules of some other version? Will Hell not break sooner or later?

Here is another scenario: said module is not needed by the system yet so it is not installed. You install the latest version system-wide and your program works. Then somehow a system upgrade or you installing an app requires that a lower version of said modules needs to be installed and is installed by the system, overwriting your installation. Now your program does/may not work. Go figure that out.

I therefore ++ 1nickt's suggestions (whether that is perlbrew or any other equivalent, that may be a "religious issue").

Irrelevant blabber: once on a mac-lion-something I needed a higher gcc version. I insisted on installing it as root, overwriting system-dependent gcc. Indeed hell broke, nothing worked, not even a terminal. I was a bit terrified because that was $work's machines. Of course being the old-unix-hand that I am I fixed the problem within the hour but it was scary to be accountable to some idiot boss the next day.

bw, bliako

Edit: Mac is notorious for relying on specific versions, e.g. gcc.