Best practice for releasing Perl modules to staging and live

[Paul Johnson]

On Mon, May 18, 2009 at 04:03:19PM +0100, ian wrote:
> Paul Johnson wrote:
>> On Mon, May 18, 2009 at 02:22:09PM +0100, ian wrote:
>>
>>> How best to ensure different environments have the same versions of 
>>> Perl  modules?
>>
>>> Any other methods that should be considered?
>>
>> Pick a packaging system - preferably the one which is native to your OS.
>> Build your packages on your development system.  Only install packages on your
>> test and prod systems.
>>
> Are you advising to (re)build CPAN Perl modules this way, or are you  
> just describing what to do with our own Perl modules?
>
> One company I worked at did just this for CPAN modules, but it was a  
> many-day exercise to work out all the dependencies of (for example)  
> Catalyst and to build them all into Debian packages.

The way I do this is to build perl and all the modules I need on the
development machine.  Then I package up the whole lot as a single
package.  The application itself is also packaged up (in my case into a
number of separate packages, but that it not important).

This way, there is no need to worry about (module) dependencies because
I am packaging my perl environment as a whole.  I am never going to
update just a single perl module without rebuilding the entire package.

Building everything myself also ensures that I have complete control
over how it is built.  You could use the perl and cpan modules as
packaged by your vendor, but for anything you care about I would suggest
building your own.

-- 
Paul Johnson - paul at pjcj.net
http://www.pjcj.net