Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Hi Monks, I am trying to install some Perl modules that I need to, but I seem to not getting what I need. So, I do this:
cpan:>install CPAN::Meta::Requirements Running install for module 'CPAN::Meta::Requirements' Running make for D/DA/DAGOLDEN/CPAN-Meta-Requirements-2.140.tar.gz Has already been unwrapped into directory /usr/share/perl5/build/CPA +N-Meta-Requirements-2.140-0HqGc4 Has already been made Running make test Has already been tested successfully Running make install Already done
but then I get this:
Can't locate CPAN/Meta/ in @INC (@INC contains: /usr/lo +cal/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl / +usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at t line 2.
I don't know what am I doing wrong...

Replies are listed 'Best First'.
Re: Confused about Perl module installation
by choroba (Archbishop) on Dec 16, 2019 at 15:15 UTC
    Do you use the system perl, Perlbrew, or a custom installation? Do you use local::lib? Do you run cpan as an administrator? What's your perl version?

    CPAN::Meta::Requirements is core since 5.15.7.

    map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
      Hi choroba, thanks for your time! So, as I see it, I have v5.16.3 and Centos 7. I configured it to not use local::lib, so it installs whatever I install (as root) system-wide. Should I not run cpan as root? These modules are required by a web server that I am moving to a new VM.

        Anonymous Monk:

        I've seen two common cases that give the symptoms you describe:

        1. There could be multiple versions of perl on your system. So when you log in as root and install modules from cpan, it affects the version of perl used by the root account.
          Note: If your operating system provides Perl, it's often because some of the operating system utilities use perl. So there's an operational risk in upgrading the system perl or installing/upgrading modules. Similarly, if your application is using perl, you don't want an operating system upgrade to cause you a problem by changing your perl under you (possibly exposing you to a new bug) or changing a module version. That's why we advise people to leave the system perl alone and install a different perl for your application and/or local use.
        2. The other common case is that some of the directories in your @INC path have restrictive permissions. So while the root account can access the directories to install the module(s), other accounts (such as the account your webserver is running under) don't have access, so they won't be able to find the module(s).

        Some people will compile a new perl from source manually, or use a tool like perlbrew to automate the process. I use perlbrew because it makes managing multiple versions of perl on my box simple. That way, my development box has all the versions of perl any of the production servers use.

        Since production changes have to go through testing and review processes, not all servers always run the same version of perl. So to fix a problem for a particular server, I can tell perlbrew to switch to a particular version, check out the application code and get to work. Or if I want to upgrade perl on a server, I can tell perlbrew to install the new version and run the application through its paces on my dev box to see if there are any problem areas.


        When your only tool is a hammer, all problems look like your thumb.

        Have you made sure that the module is not already available as a package by your OS vendor? I guess that Centos has perl-CPAN-Meta-Requirements as the vendor package. If you want to use the system Perl, you're well-advised to use the system package manager to install packages there.

Re: Confused about Perl module installation
by Anonymous Monk on Dec 17, 2019 at 00:46 UTC
    When the Perl interpreter looks for packages, it refers first to the PERL5LIB environment variable, then to a built-in list that is hard coded into the executable when it is built. This is not the list that is consulted by the cpan command when it decides where to install a package. If the two do not correspond, then you will see the behavior that you are now seeing.
      When the Perl interpreter looks for packages, it refers first to the PERL5LIB environment variable, then to a built-in list that is hard coded into the executable when it is built.

      But wait, there's more!