[sf-perl] [announce] Pinto-0.026

Fred Moyer fred at redhotpenguin.com
Fri Dec 16 22:17:58 PST 2011


[late to the discussion]

2011/12/7 Bill Moseley <moseley at hank.org (mailto:moseley at hank.org)>:
> 2011/12/8 Jeffrey Thalhammer <jeff at imaginative-software.com (mailto:jeff at imaginative-software.com)>
> 

> Currently, some developers just check-out from svn the in-house module they
> need and install in local::lib, but mostly they get installed system-wide,
> which isn't a great approach.
> 
> Can anyone offer comments on how this is done in your organization?
I try to develop using a locally installed copy of perl via perlbrew if possible when in a shared development.  This has the disadvantage of taking a couple hours to get a full set of needed Perl modules installed, but does return some long term benefits such as being able to install whatever module you want whenever you want without breaking modules that are shared between developers.

Where it tends to run up against a wall though is if there is XS or swig code local to the organization.  Usually it doesn't compile because that code is developed in a different environment by C developers, and they don't always package it with the neatness of CPAN modules.

This also requires you build your own versions of Apache and mod_perl if you develop against a mod_perl based web server.  Which can be a hindrance to some developers, even mod_perl maintainers like myself.  I'm referring mostly to making sure that perl is compiled with -fPIC through perlbrew, and then compiling against that.  However, that detail usually doesn't come to light until you're already built perl without -fPIC.

Given my druthers, I use perlbrew and develop locally on my own machine with mod_perl and postgresql built from scratch, but sometimes you work with code where the database is either too unwieldy to setup, or not something anonymized enough that it won't have to be a concern if my laptop is stolen, so you have to connect to a remote database.  Pretty happy with that compromise, as you still get the low latency benefits from working in a localhost environment.


More information about the SanFrancisco-pm mailing list