Question

I have yet to come up with a satisfactory way to manage the development, build, and deployment of my Perl applications. I’d like to hear how you have solved this problem and/or what you would like to have in an application build system that you don’t have now.

Please describe your application type (is it a web app, does it run on a server, or do you bundle it using PAR or PerlApp so that you can run on perlless systems).

Key things a build system should provide:

• Control of libraries.
  • It should be possible to check a library distribution out into my dev directory to use it in my build.
  • It should be easy to execute perl with an @INC value that will use the appropriate directories.
  • It should be possible to get a list of modules that are being sourced from the system perl install.
• Makefile/Build integration
  • It should be easy to do a global test across the entire application by issuing only one make test or similar command.
• Version control friendly
  • structure should not interfere with normal usage of CVS, SVN and other version control systems.
• Cross platform
  • System should operate on Win32 and Unix derived systems at minimum.
  • Ideally, tools should function identically in all places where perl operates.
• Single Perl install
  • It should not be necessary to install perl into a special directory as part of setting up the environment.
• Easy start up
  • Starting an application should be a mostly automated process. Something along the lines of Module::Starter or h2xs should be available to layout a basic structure and create any standard files.

Cross-posted at Perlmonks.

Answer 1

There’s a lot that I could write about this

1. Control of libraries – I create my own versions of CPAN with just the modules I want. The latest versions of App::Cpan has several features, such as the -j option to load one-time configurations, to help with this. Once you have this, you can distribute it on a thumb-drive or CD which has all of the modules, the CPAN.pm configuration, and everything else you need. With a little programming you create a run_me script that make it all happen.

2. Makefile/Build integration – I don’t integrate the Makefiles. That’s the road to disaster. Instead, I do integration testing with the top-level application module, which automatically tests all of its dependencies too. The -t switch to the cpan command is useful to test the module in the current working directory:

   cpan -t .

There are various intergation testing frameworks that you can use too. You set PERL5LIB to something empty (with only have the core modules in the hard-coded @INC directories) so cpan has to install everything from scratch.

3. Version control friendly – it doesn’t much matter what you use. Most things have some sort of export where you can get everything without the source control stuff. Git is very nice because it only has a minimum of pollution in the normal cases.

4. Cross platform – everything I’ve mentioned works just fine on Windows and Unix.

5. Single Perl install – this part is more tricky, and I think you’re going in the wrong way. Any time multiple things have to depend on the same perl, someone is going to mess it up for the others. I definitely recommend not using the system Perl for application development just so you don’t mess up the operation of the system. At the minimum, every application should install all non-core modules into their own directories so they don’t compete with other applications.

6. Easy start up – that’s just a simple matter of programming.

BONUS: I don’t use Module::Starter. It’s the wrong way to go since you have to depend what Module::Starter thinks you should do. I use Distribution::Cooker which simply takes a directory of Template Toolkit templates and processes them to give them your distribution directory. You can do anything that you like. How you get the initial templates is up to you.