|Pathologically Eclectic Rubbish Lister|
Re^3: how to improve: use MODULE VERSION LISTby kcott (Bishop)
|on Jan 08, 2017 at 05:45 UTC||Need Help??|
Thanks for the clarifications. To be honest, it sounds like your problems are more political than technological. You probably need to implement a plan for upgrading software that's agreed to by all parties: probably involving rigorous testing, appropriate notifications, sign-offs at various levels and so on. I'll leave you to work on that. See also codiac's comments.
Here's a suggestion that doesn't require altering @INC directly or via the lib pragma, nor does it rely on checking version numbers. (I've used version numbers in the examples below purely for identification purposes, the solution itself doesn't need them.)
Some up-front information:
Let's say you've got an xyz module. That's in production and lives in directory old. Here's old/xyz.pm:
You can use that with or without a VERSION; it might have a LIST, which could be empty.
Now, let's say that a new version of the xyz module becomes available. It has some features the developers want. You install it in directory new. Here's new/xyz.pm:
For the purposes of demonstration, that's identical to old/xyz.pm except for the version number. Attempting to use it by just specifying VERSION doesn't work because old/xyz.pm is found first in @INC (i.e. the problem already discussed).
What I suggest you do is create a new module that only needs to be very simple. I've called this Bleed::xyz and put it in the current directory (i.e. the last place in @INC to be searched). Here's ./Bleed/xyz.pm:
Now version 2.0 of xyz can be used with all the various combinations of VERSION and LIST.
When version 2.0 of the xyz module is accepted into production, and assuming that involves moving new/xyz.pm to old/xyz.pm, you'll need one, very minor change to Bleed::xyz (i.e. s/new/old/). All existing code should continue to work. You can change instances of use Bleed::xyz to just use xyz at your leisure.
"BTW, why is the '.' location not good in the @INC?"
I didn't say that. I said:
"... you end up with '.' at the front of the list: not a good idea.".
Consider someone's who's bad. In /home/bad they write code with names like strict.pm, warnings.pm, autodie.pm, etc. that all do bad things. They then run your code from /home/bad. If @INC starts with '.', bad things will happen.