http://www.perlmonks.org?node_id=89830


in reply to The Future - Shipping Applications Written in Perl

Coming from a decidedly java-centric background, and working with people who do not use Perl regularly, I have also felt the need for this.. I'll just note a few thoughts I've had on the topic, a full blown solution, unfortunately, isn't something I can offer... any way you ship an application, there are bound to be tradeoffs..

The first, much maligned method is compilation as an executable.. as merlyn has pointed out, it doesn't promote reuse of the Perl interpreter (essentially, an interpreter is bundled with each executable), and executable compilation (at least on Win32, where I use it) is still a young technology.. You need to explicitly include modules sometimes, sometimes the darned thing just doesn't work anyway... with that being said, its still great way to ship applications (yes, all 2+ mb of it).. No one needs to know or care about which language the app is written in, and excluding any fatal errors, no one will ever know (on fatal errors, you get a PERL2EXE prefixed error message)...

Unfortunately, a Perl interpreter is not standard on either MacOS or Win32.. this is where Java might have an advantage, because a valid JRE is usually installed with a browser and at a pinch, a Java app can run on that JRE (it usually dies horribly, but an option with a small chance of working is better than no option at all :o). Visual Basic, I believe is similarly blessed, at least on Win32

Other methods.. well, I've discussed bundling in the form of a question, some time back.. and I think its a valid method to try.. especially for modules which are not part of the standard distribution.. a reasonable thing to do is to use lib and have the module as part of the source itself.. This still doesn't solve the problem of the interpreter on the machine though..

I don't know about the feasibility of the next method, but Python and Java both have some form of it.. essentially, bytecode compile the source, make a bytecode image (with all the necessary module code compiled in) and ship with a scaled down version of the interpreter which just executes code (it doesn't need to load, locate or compile any code, just execute it).. I don't know if its practical, really, or how much of a saving this will be... but its something that could be borrowed from the other languages that use this method...
Note to self: look at the backend modules on CPAN

Umm.. the final solution of course, is an automatic installer.. if there are any Java people out there, Webstart is one tool that is really good.. it automatically installs and runs an application, so that distribution is taken care of.... this however, requires a net connection and that is not always feasible..

Oh, and the absolute final solution (I promise :o): download the appropriate Perl binary or compile from source, and start maintaining a Perl installation on the client machines.. guaranteed to work, and with things like CPAN.pm, PPM and other install managers, the administrative hassles can only lessen...

Random pie in the sky idea: Have a Perl installation on a server, and have clients contact this known server for compilation.. sort of like RPC or SOAP, if you like.. (please don't flame me about the security implications, I know, I know! :o) at least, you won't need to install Perl on all the machines...

Well.. apologies if you fell asleep during this rambling reply :o) wake up now, and go get yourself a Perl installation if you don't have one already.. that seems to be the best solution for now...

Replies are listed 'Best First'.
(tye)Re: The Future - Shipping Applications Written in Perl
by tye (Sage) on Jun 20, 2001 at 18:52 UTC

    Great reply to an important question. I have only minor additions.

    I've found things like Perl2exe to be too "clever" and thus not overly hard to break. I find the idea of identifying which files are actually used by a script and packaging them all up together to be very handy. But I find it a bit silly to package them all up into an executable that tries to run the script when you run it. I'd rather just pack them up into a (possibly self-extracting) zip file that expands to the script and a subdirectory contain the bits of Perl you need for it. By doing this, you won't break anything (other than failing to identify some of the required files, which is why they invented testing).

    For the Perl scripts I've distributed, the solution has always been to include a full version of Perl w/ any needed extra modules and give the recipient the option of installing that or maintaining their own copy of Perl if they prefer (or just send the script, of course, but that isn't the kind of case we are discussing here).

    Packaging up a version of Perl for a specific operating system is nearly trivial (you use zip or tar+gzip).

    Under Win32, the one minor problem is that if you want to allow the recipient to install more modules then you have to update Config.pm based on where the recipient unpacked your archive. But that code isn't hard to write and prewritten versions can be found.

    Under Unix, the (perhaps larger) additional problem is allowing the recipient to specify what directory Perl gets installed into. I've previously built Perl such that the @INC paths were rediculously long and then would patch the perl executable to replace these based on the install location chosen. Quite a hack, but it worked. /:

    For larger subsystems, having a "private" copy of Perl included in the subsystem makes a lot of sense because Perl isn't really that big compared to most subsystems and doing this makes your QA department's life manageable.

    Perl6 is intended to support "compile to Java engine" so you could ship your Perl6 applications as "compiled Java".

            - tye (but my friends call me "Tye")
Re: Re: The Future - Shipping Applications Written in Perl
by John M. Dlugosz (Monsignor) on Jun 20, 2001 at 23:01 UTC
    Re bundling the interpreter with every program: If Perl 6 moves more features out of the core as promised, it should continue to shrink. The perl DLL from ActiveState is currently 600K, up a bit from older versions. That's not too terribly large. Compare that against vbrun*.dll which as I recall was over a meg, years ago when that meant something. In Visual BASIC, a program didn't have to ship the DLL; it could provide it separatly just in case. With a web-install ability to just download needed parts, I think this can work with Perl software too. For distributing on media, like a CD, just include everything.

    Basically, we are talking about good installer technology here. The Perl interpreter and library collection would be self-maintaining, so people could use it without developing for it.

    —John