A bag o' tricks from the Perlmeister

Creating Packages

CPAN accepts tarballs, but to give your users more convenience, you may want to convert the build into a package for the target distributions such as Debian or RPM. If you are not worried about downloading about half of all CPAN modules ever created as dependencies, you can go for Dist::Zilla. For those who prefer a more lightweight approach, I recommend the Ruby tool fpm [7].

With a reasonably fresh Ruby version, the practical tool installs itself after you type gem install fpm. It supports numerous options, but to bundle a number of files into a package using one of the supported formats (RPM, Debian, or OS X), you will only need to specify the package type with -t and point fpm to the source files under usr to be included with -s usr.

In the directory, as the tree command in Figure 4 shows, the files are stored exactly as they will be placed on the system when installed, that is with the foo script in usr/bin/foo and the Perl module Foo.pm in usr/lib/perl5/site_perl/Foo.pm. The example specifies Debian as the package format (-t deb); a .deb file with the specified version number is thus created.

Figure 4: The package bundling tool fpm, which dumps the files residing below usr into a Debian package.

The tool is fantastically easy to use and shields developers from what are sometimes quite tragic implementations of specific package bundlers, such as rpmbuild. It can also resolve dependencies on other packages, and it is certainly something that should not be missing from any tool box.

Into the Box

Some new projects may have dependencies on a whole bunch of CPAN modules, for which packages for the end user's distribution may not exist. The time-consuming workaround of opening a CPAN shell and initializing, followed by installing a few dozen modules, which in turn have dependencies on more modules, is something end users shouldn't be burdened with. This is especially true if the target group normally has nothing to do with Perl, and only wants to use a new command-line utility provided by the project.

In these cases, the Carton CPAN module provides invaluable services, because it automatically resolves dependencies stored in a cpanfile with the following format:

requires 'Log::Log4perl', '1.0';
requires 'Pod::Usage', '0.01';

After onboarding indirectly dependent modules, with carton install, it launches a build process for the whole enchilada in a newly created local directory. If you then push the results into the directory of the utility discussed in the previous section, fpm, the tool puts together a package that will work on the target systems regardless of installed modules, thus resulting in a robust release.

Bugs? What Bugs?

All programmers make mistakes, and sometimes you need to put on your crime scene cleaner suit and trudge through the code with Perl's debugger to see where the problem lies. If the problem does not occur at the beginning of the script, but in the middle of a module, you can set a break point in the associated function, step through to the point in question manually, or use my favorite Perl trick: A statement planted at the desired location in the code, like this:

$DB::single = 1;

stops the debugger started with perl -d <script> and c at precisely this point. But, sometimes perl rummages through code even before the actual show in the main program begins. For example, the ORM wrapper Rose::DB creates its data structures while a database module is being loaded with the use My::Data command.

How can you launch a script that uses this module, so that the debugger stops in My::Data and not just in the first line of the main program? If you add the following line

BEGIN { $DB::single = 1 }

at the beginning of the script, the debugger stops at the first executable line, regardless of whether it's in the main program or somewhere else.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Perl: CPAN Additions

    Many people have declared the granddaddy of scripting, Perl, to be dead. A look at new items in the CPAN software repository, however, shows that the community is still quite active.

  • Perl: Testing Modules with Docker

    If you want to distribute your programs across multiple platforms, you need to prepare them to run in foreign environments from the start. Linux container technology and the resource-conserving Docker project let you test your own Perl modules on several Linux distributions in one fell swoop.

  • Perl – Print Test

    Cautious administrators will want to make sure a Linux installation is still working as intended after an update. A simple test suite offers that assurance.

  • Perl: Travis CI

    A new service on travis-ci.org picks up GitHub projects, runs new code through test suites, and notifies the owners if the build fails. Its API enables Perl scripts to gather historical build data, including who-broke-the-build tabulations.

  • Perl: Cucumber

    The Cucumber test framework helps developers and product departments jointly formulate test cases, not as program code, but in plain English. The initially skeptical Perlmeister has acquired a taste for this.

comments powered by Disqus

Direct Download

Read full article as PDF:

Price $2.95