I curate a repository of cpan modules @WORK that is shared across the enterprise. Unfortunately, I am trying to serve two masters: "run the biz" and "change the biz". The RTB folks don't like changes to their environment, and fight vehemently when modules upgrade (b/c they have production systems dependent upon old code). By contrast, the CTB folks love the bleeding edge and want to try new things, build new tools, etc.
So, when I built Perl for the next operating system, I added a new directory to the default @INC where I can put additional, non-core, modules (or new versions of existing modules) for the CTB folks. This works fine if the "newer version" of a module comes earliest in the @INC list. But what happens when something in the corelist is updated? DHOH!
So after much GIYF, I found this very troubling statement:
"Please recall that Perl interpreter will STOP trying to search [additional directories in @INC] once it finds the file in one of the locations, without trying to see if the file is in later locations as well. E.g. if /usr/lib/perl/This/Here/MyModule2.pm exists, then Perl will not look for, nor care about the existence, of /opt/custom/lib/This/Here/MyModule2.pm." Stack Overflow
Is there a better solution than "use lib reverse @INC" to get the newer module that is further in the @INC list?
For example, autodie v.2.23 is in the core for perl. So I build the newest autodie v.2.29, and it now lives in the non-core extras modules path, which is part of the default @INC.
So again, I ask: is there a better solution than "use lib reverse @INC" to get the newer module that is further in the @INC list? Is there a way to change the module search heuristic in Perl so that all the locations are scanned when you specify a VERSION (and/or a LIST)? Am I missing a new feature that solves this problem?
TIA for your wisdom and insights.