Re: Why not include version.pm

[Tanktalus]

And thus, all the more reason to use a separate copy of perl that is under your control, not your distro's control. This also means things like saving off a copy of the modules you need. Stability, predictability, and control. You're no longer at the mercy of a distro that ships modules that have bugs in them (you can apply bugfixes to your private perl), nor in a distro that upgrades a module to be incompatible with you (you simply don't upgrade that module until you can fix your code to match). And you no longer care about which distro is being used - whether it's CentOS, Gentoo, SLES, Debian, Ubuntu, or whatever, you just work. Makes upgrading the distro safer, too, since you won't rely on the system perl, and you know that your stuff will keep working because its perl version is frozen to whatever you've tested.

But maybe that's just me.

[Your Mother]

I agree with you but I think the underlying topic here is installing Perl based software on machines over which you have no control. Having to ship a full version of Perl just to do that is a bit of burden compared to be able to rely on, say, the core features of 5.6/5.8, which really should be stable and available (excepting a couple caveats like CGI) even now.

Python's instability as an install tool (v2/v3 incompatibility) is what soured me on it before I tried anything but installing third party stuff using it. Well, that and the too often rabid community. Hate to hear the same kind of broken experience is in the cards for first time exposure to Perl.

Update: Of course, I just checked and version isn’t core. DERP, it is, checked badly, first in 5.9 :P