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

[Qiang]

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.

thoughts?

[perrin]

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.

[Qiang]

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.

[perrin]

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.