* On Thu, Apr 09 2009, Arthur Corliss wrote: > On Thu, 9 Apr 2009, Eric Wilhelm wrote: > >>> A common plaint I hear about perl code *from people outside the >>> community* is that we have too many dependencies and our code is too >>> hard to install. ... If on top of that you want >>> them to *upgrade perl* they're going to think you're mad. >> >> Ruby didn't seem to have a problem getting installed. > > There's a huge difference in installing a new software stack altogether and > updating something that's there by default on just about every UNIX out > there. Given how many OS's use Perl scripts for administrative tasks I > wouldn't necessarily be surprised to learn that some of them also bundle > some CPAN modules with their package just to keep that running. So, if your > vendor doesn't update the system perl, you shouldn't be overwriting it with > no regard to the consequences. > > Even more so when you have people installing modules via CPAN and > outside of package management. They always run the risk of updating perl > and forgetting a litany of other modules that were installed for various > scripts, etc., which use XS modules, etc. The anticipation of that kind of > triage is more than enough reason for a lot of people to avoid updating > perl. How many sys-admins and non-developers are aware of perlocal.pod?
Most people I know compile one perl for each of their applications. The OS perl is for the OS, not for you. (OK, and packages the OS installs. Basically, if you plan on modifying anything perl touches in any way, you want your own perl install for that. Otherwise, yeah, you will break your OS. Why would this surprise anyone?) Admittedly, it would be nice if this process were easier, although I think using local::lib for development and PAR for deployment is a pretty good off-the-shelf solution. Regards, Jonathan Rockway -- print just => another => perl => hacker => if $,=$"
