Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

Re^2: Professional development with Perl - how it's done?

by Qiang (Friar)
on Apr 06, 2007 at 13:18 UTC ( #608661=note: print w/replies, xml ) Need Help??

in reply to Re: Professional development with Perl - how it's done?
in thread Professional development with Perl - how it's done?

I have been looking for ideas about how to automate Perl app deployment and module managment.

currently, we have all the commonly used modules (such as CGI::Application and other in-house modules) in a central perl lib directory and all apps use it from there. problem may arise if a module gets upgraded with API changes and such. but i think testing may help us stay away from trouble.

to your reply, I am wondering why not unpack all needed modules locally once for your app in development and save to cvs. when deploy to the production, just cvs out. be done with it? (the only reason i can think of not doing it is unless you need to deploy to different OS). rebuilding same modules on dev,QA,production sound tedious.

or, you can keep all unpacked modules in a central location, copy to new app when needed without rebuilding it for every release.


  • Comment on Re^2: Professional development with Perl - how it's done?

Replies are listed 'Best First'.
Re^3: Professional development with Perl - how it's done?
by perrin (Chancellor) on Apr 06, 2007 at 14:55 UTC
    Compiling once the way you describe will only work if you are sure you never need to support another OS, different hardware, or a different version of Perl. These things will also change over time. You will want to upgrade your OS and suddenly find you have to recompile all of those modules by hand. Building an automated installer makes this easy, and has made it easy to deal with adding new modules.
      now our app runs on Perl 5.8.7 under solaris only. I have read from "perl install" that XS modules under 5.8.* are generally compatible.

      but i do agree with what you said. I think i will go the route of keeping modules local to the app and also keeping a copy of unpacked modules to avoid rebuild for each app. of course a copy of module src.

      in case of change, Krang::Platform seems to be easy to be adopted in our environment.

      thank you.

        If you want a sort of "best of both worlds" approach, you could build a system that can compile your modules, and then just share them around by either making tar.gz packages or using NFS. Then you can quickly recompile for a new platform, but don't need to do it on every machine.

        The way Krang handles this is by building binary distributions, which are just tar.gz packages with everything compiled.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://608661]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (4)
As of 2020-10-31 08:16 GMT
Find Nodes?
    Voting Booth?
    My favourite web site is:

    Results (287 votes). Check out past polls.