views:

517

answers:

8

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.

+1  A: 

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.

davehurt
Although it is true that a simple program can live in a single file which can be directly executed, more complex programs should have submodules, resource files, test scripts, configuration, and other files that go along with the main program. In some cases, these modules are written in C and therefore do require a build step. Even without this, a simple framework for deploying the project or building some type of packaged installer may make sense.
Kevin Panko
+6  A: 

You should begin with:

use strict;

;-)

Mike Mu
I already "`use strict;`" and "`use warnings`".
Brad Gilbert
+3  A: 
#!/usr/bin/perl -w
Beano
I already "`use strict;`" and "`use warnings`".
Brad Gilbert
See "What's wrong with -w and $^W in http://perldoc.perl.org/perllexwarn.html
Sinan Ünür
The -w flag enables warnings globally, even inside library modules. The "use warnings" statement only turns on warnings inside your file.
Kevin Panko
+6  A: 

perldoc perlnewmod

William Pursell
+10  A: 

These are worth looking into:

Sinan Ünür
+11  A: 
  • 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).

DVK
You may actually want to try `Module::Build` .
Brad Gilbert
+6  A: 

How do I start testing?

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

Kevin Panko
+2  A: 

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.

jrockway