Best practice for releasing Perl modules to staging and live
paul at pjcj.net
Tue May 19 15:22:59 BST 2009
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
More information about the london.pm