On Feb 26, 2007, at 1:16 PM, Blair Zajac wrote:
If MacPorts provides a newer version of a module than the base Perl, then Perl should pick that one up by default. I don't like the few modules we have that clobber files from other ports, as this is just messy.
What about when the module author changes the API? It's not totally unreasonable for scripts to assume that CORE modules won't have API changes (and that is probably why the default @INC ordering is the way it is). Incidentally, the 'normal' way of upgrading CORE modules is to clobber the installed one (yes, I don't like it either).
Debian and Ubuntu can have local modules in front of the base modules:
... which isn't as interesting to me as if the perl-distributed hints file has a different @INC or not (if it does, I would find it persuasive to change macports behavior, if not, then not so much).
I don't think too many people pay attention to @INC until they need it, or they wonder why their newer module is not being picked up.
So I vote to have out Perl have it's @INC reordered to have site_perl and vendor_perl first. I don't think making this change will break many things, will it?
It won't break things as long as newer modules never change API or semantics. I would guess that CORE modules aren't very unstable and it probably won't be a problem, but I wouldn't want to bet on it. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+