note
chrstphrchvz
<p>Asker has already found a solution as of writing this, but here are some other thoughts I have were this not resolved:</p>
<p>Some reasons that I advocate first trying to install modules through a package manager, if you're using Perl from one:
<ul>
<li>All dependencies (including non-Perl ones) will automatically be satisfied.</li>
<li>For modules containing C code, any peculiarities in compiling for your platform will already be handled.</li>
<li>If something goes wrong with using the module installed from a package manager, cleanup is easy: use your package manager's uninstall/remove command.</li>
</ul>
(If you were installing from cpan/cpanm, you would have to gather all non-Perl dependencies, and then specify any platform-specific workarounds yourself. Uninstalling Perl modules with cpanm is possible, but it is an afterthought.)</p>
<p>However package manager modules do have a higher chance of being outdated, since someone has to manually incorporate an update. (Or, as on many Linux distributions, there is a "feature freeze" imposed on packages, meaning that new upstream releases usually have to wait until the next OS release.)</p>
<p>To my knowledge, any modules installed from cpan/cpanm (e.g. path containing "site_perl") will take priority over modules installed using a package manager (path with "vendor_perl"). If a "site_perl" module is not properly installed, or is not completely uninstalled (e.g. empty directories left behind by <tt>cpanm --uninstall</tt>), your Perl program will fail to load the module in "site_perl" (because it thinks it's there), and not bother trying the module in "vendor_perl" instead; some manual cleanup might be involved if this happens.</p>
11101886
11101968