Order of paths in @INC

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

Fellow Monks,

when I update a module, sometimes problems arise. The old version persists or using the module leads to a compilation error. I have investigated this matter earlier, which lead me into writing a program for finding duplicate modules in site_perl and vendor_perl but it doesn't help always.

More importantly, I think that it is not the right way to go, to remove the modules from .../vendor_perl/... when a new version is in .../site_perl/.... I had the @INC array printed and for some reason, the vendor_perl branch comes before the site_perl branch. I believe that it is the wrong order since the CPAN module installs things into site_perl. I haven't found where this is set up. Yes, I know, I could set PERL5LIB to .../site_perl/... but I would much rather figure out why it is in this order and where it is set up.

Comment on Order of paths in @INC

Replies are listed 'Best First'.
Re: Order of paths in @INC by locked_user sundialsvc4 (Abbot) on Nov 13, 2007 at 13:19 UTC
(1) The base-definition of "@INC" is specified at compile-time when 'perl' itself is built. Some "distros" put site_perl first; others (like Gentoo) put vendor_perl first. (2) CPAN's install-behavior is determined by one of its "o conf" settings; PREFIX is usually the best. (3) Beyond that, the PERL5LIB environment-var puts things at the front of @INC. I resigned myself quite some time ago to specifying PERL5LIB in either a user-specific or site-wide login script, setting CPAN appropriately (in a non-root "maintenance" account used for such things), and installing "my stuff" into a user-specific or site-local location of my choosing. Since my OS (Gentoo) drives most of "its" stuff using Perl, and using its own methodologies to do so, this keeps "their" stuff mostly unaware of "my" stuff.
Re: Order of paths in @INC by shmem (Chancellor) on Nov 13, 2007 at 16:36 UTC
I have the notion that the `vendor_perl` tree is for those OS vendors as bundle perl with the OS and have either specific modules for their OS or provide some CPAN modules with their perl install as packages suitable for that vendors packaging tool. `site_perl` is what on the OS level is (has been?) `/usr/local` - stuff specific for that particular machine, so CPAN is doing the right thing installing into `site_perl`. You should not upgrade modules living in the `vendor_perl` tree via the CPAN shell, but rather via your vendors package repository. If your vendor lags seriously behind, complain to them ;-) --shmem _($_=" "x(1<<5)."?\n".q·/)Oo. G°\ / /\_¯/(q / ---------------------------- \__(m.====·.(_("always off the crowd"))."· ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}	[reply] [d/l] [select]
Re: Order of paths in @INC by locked_user sundialsvc4 (Abbot) on Nov 15, 2007 at 16:59 UTC
I would rather sternly advise you not to (!)-around with the vendor-perl and really even the site-perl directories, especially if that's what your Linux distro uses to maintain its software-update system! "If you don't know how it got there, or why it's there, and yet you have no reason to suspect that it was somehow 'planted there' with hostile intent, leave it alone until you do know." It's much safer, I think, to set up PERL5LIB (and your local CPAN-configuration) to put "your stuff" in an entirely separate place, which the user that's responsible for doing system-maintenance won't "see" while he's doing that chore. You'll probably wind up using this facility quite a lot... because if you are (say) maintaining multiple web sites for different clients, you need to keep every one of those configurations separate, and this is a good way to accomplish that.