Question

I have an app that I pack into “binary” form using PerlApp for distribution. Since my clients want a simple install for their Win32 systems, this works very nicely.

Now a client has decided that they need to run all unit tests, like in a standard install. However, they still will not install a normal Perl.

So, I find myself in need of a way to package my unit tests for operation on my client’s systems.

My first thought was that I could pack up prove in one file and pack each of my tests separately. Then ship a zip file with the appropriate structure.

A bit of research showed that Test::Harness::Straps invokes perl from the command line.

Is there an existing tool that helps with this process?

Perhaps I could use PAR::Packer‘s parl tool to handle invocation of my test scripts.

I’m interested in thoughts on how to apply either PAR or PerlApp, as well as any thoughts on how to approach overriding Test::Harness and friends.

Thanks.

Update: I don’t have my heart set on PAR or PerlApp. Those are just the tools I am familiar with. If you have an idea or a solution that requires a different packager (such as Cava Packager), I would love to hear about it.

Update 2: tsee pointed out a great new feature in PAR that gets me close. Are there any TAP experts out there that can supply some ideas or pointers on where to look in the new Test::Harness distribution?

Answer 1

I’m probably not breaking big news if I tell you that PAR (and probably also perlapp) aren’t meant to package the whole test suite and plethora of CPAN-module build byproducts. They’re intended to package stand-alone applications or binary JAR-like module libraries.

This being said, you can add arbitrary files to a PAR archive (both to .par libraries and stand-alone .exe’s) using pp’s -a switch. In case of the stand-alone executable, the contents will be extracted to $ENV{PAR_TEMP}.”/inc” at run-time.

That leaves you with the problem of reusing the PAR-packaged executable to run the test harness (and letting that run your executable as a “perl”). Now, I have no ready and done solution for that, but I’ve recently worked on making PAR-packaged executables re-useable as more-or-less general purpose perl interpreters. Two gotchas before I explain how you can use that:

• Your application isn’t going to magically be called “perl” and add itself to your $PATH.
• The “reuse” of the application as a general purpose perl requires special options and does not currently support the normal perl options (those in perlrun). It can simply run an external perl script of your choice.

Unfortunately, the latter problem is what may kill this approach for you. Support for perl command line options is something I’ve been thinking about, but won’t implement any time soon.

Here’s the recipe how you get PAR with “reusable exe” support:

• Install the newest version of PAR from CPAN.
• Install the newest, developer version of PAR::Packer from CPAN (0.992_02 or 03).
• Add the “–reusable” option to your pp command line.

• Run your executable with the following options to run an external script “foo.pl”:

  ./myapp –par-options –reuse foo.pl FOO-PL-OPTIONS-HERE

Unfortunately, how you’re going to teach Test::Harness that “./myapp –par-options –reuse” is a perl interpreter is beyond me.