I'm starting a new project in Perl, how should I begin?

Question

The question is about how to start a new Perl project.

• How should I create the skeleton of the Project?
• What should the directory layout look like?
• How do I start testing?
• What build system should I use?
• Should I even use a build system?

I have been writing Perl programs for a while now. I only started to run tests on my recent programs. I know Perl the language fairly well, now it is time to learn the way to build full blown Perl projects.

I already add these to the beginning of every Perl file:

use strict;
use warnings;
# and occasionally
use autodie;

I have also used Moose.

Answer 1

It depends on the type of project you are working on.

Is this a web application, a server application?

Perl is interpreted, so there is not really any build or compile step.

Answer 2

You should begin with:

use strict;

;-)

Answer 3

#!/usr/bin/perl -w

Answer 4

perldoc perlnewmod

Answer 5

These are worth looking into:

• Module::Starter
• Module::Release

Answer 6

• How should I create the skeleton of the Project?

  Along with the basics you mentioned, any CLI Perl script should have a command line processing (GetOpts or equivalent) at the start. No generic skeleton items otherwise.

• What should the directory layout look like?

  Outside of having 4 separate directory trees for libraries, executables (e.g. *.pl), web pages, and config files (that often are Perl code), no "standard" directory structure exists beyond the usual set of sub-directories for modules which you should already be familiar with (e.g. A::B::C should be a file in A/B/C.pm)

  Sometimes having a separate /test/ tree (especially for modules but really for anything) is a good idea - the magic of @INC in BEGIN block allows you to automagically import test libraries into test *.pl scripts!!!

• How do I start testing?

  The Perl-specific testing items are:

  • Standard Perl testing tools (Test::More, Harness, etc...)
  • Mock objects for unit testing. There are CPAN libraries, though our company had a new mocking perl library built that was 10x better than anything on CPAN (sadly, not public domain).
  • Code Coverage!!! among the best things in Perl projects is ability to precisely evaluate your tests' coverage via Devel::Cover - both line, branch, method etc.

• What build system should I use?

  I've been building pretty complicated Perl systems for years and never saw any need for special build system outside of 2 batch jobs: one builds all the modules' POD overnight for web publishing to intranet, and one automatically runs every checked-in unit test via Harness and publishes the results.

• Should I even use a build system?

  See above. I personally don't know of any need for one despite many years of enterprise Perl development (though I would prefer to avoid the hubris trap of assuming other people can't suggest a very good reason for using it).

Answer 7

How do I start testing?

Perl has many modules that help you write and execute tests. Begin with this tutorial.

Answer 8

All my projects start with a Makefile.PL that looks like:

use strict;
use inc::Module::Install;
WriteAll();

You can flesh it out later. This gets you make test, make install, and the ability to declare dependencies.

I then create lib/My/Module.pm, t/with/some-tests.t, and so on. (I used to put scripts in bin/, but MooseX::Runnable has eliminated my need for scripts.)

I also usually add a .eproject file with some project variables, typically :mxdeclare-project-p t so that my skeletons know whether or not to generate traditional Moose classes, or MooseX::Declare classes.

Next, I run git init and git add . and perhaps add a gitignore file. (Makefile, Makefile.old, inc, blib, pm_to_blib, cover_db, nytprof*, MANIFEST, and MANIFEST.BAK are good things to ignore.)

This is all you need. I find it easier to start from nothing than it is to start from a bunch of auto-generated boilerplate I don't want.

Once the code is working, I use Github::Import to push my code to Github.