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...

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 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

Check out Perl2Exe. Active State has a similar product.

I find the idea of getting Perl to compile Java bytecode very interesting. Then we can take advantage of any java installation to run our Perl.

TGI says moo

Brian Ingerson (of Inline fame) has a couple of ideas on the subject that he explained at YAPC. It involves peer-to-peer distribution of (already compiled) modules, with a central repository storing only the MD5 for a module/system pair. this is very similar to what Napster does. This way you can get the "module distribution" from any registered user that has the same OS as you, and you can check that what you get is in fact similar to the distribution as registered in the central DB. That's pretty nifty.

The main problem to solve is how the first MD5 for a module distribution gets generated in the first place. At one point the system has to trust a (priviledged?) user.

The distribution process itself could be made transparent, a-la Inline, the first time you use a module, if it is not installed on your system the system goes out and gets it, already compiled.

The systeme could be name... NAPC (Brian had lots of cool accronyms for it, I liked NAPC Ain;t Perl's CPAN).

Stuff MD5, CPAN should move to PGP signed packages, like Debian. Every perl distro should be shipped with CPANs public keys. Then you can get your packages from anywhere, and you can be sure they are safe... as long as you got your perl from an approved supplier.

____________________
Jeremy
I didn't believe in evil until I dated it.

Good idea, in general. If I distribute a ZIP or gz or whatever with everything in it, I can provide a matching pgp sig file. But I wonder if it would be a good idea to have sig files for individual .pm files, since those can be checked after the stuff has been installed.

A mechanism like NAPC or an auto-download from an in-company server would be possible as a module in and of itself, if the core provided a way to hook the module load process. It's already been mentioned that there will be a list of implicit use's you can stick somewhere and they are used for every script. So you could install a suitable module manager, and such things could be created by the community.

Just musing, you could have a CORE::HOOKS::find_module that's called if it has been defined.

—John

But looking again at Activestate, it's not such a giant download. If perl2exe doesn't work it's probably a good idea to just install Perl.

By the way I just noticed something called PerlApp which "Turns your Perl scripts into executables, so that you can run Perl scripts on computers without installing Perl." It's in the ActiveState Perl Dev Kit, which "makes it easier to build and deploy applications on Windows." An installer maker seems (PerlMSI) to be mentioned too. Interested to hear what these are like.

Updated.

I refuse to believe that having the attitude of "I think you are stoooooopid; here's a 5Mb binary instead of 3k source" is going to win us many friends. Certainly not with the people it matters (like sysadmins, programmers, and other techies).

Sure, it might be easier for some J. Random Users, but does that matter? Isn't installation of applications something that should be left to the system administrators anyway? You don't *want* people who get easily confused install anything.

That leaves us the non knowledgeable people at home. But they are totally irrelevant when it comes to increasing the popularity of Perl in the world. If the customer can install it without caring that it's written in Perl, it certainly isn't going to increase the popularity of Perl - because the customer doesn't even know Perl is being used.

Microsoft has done enough damage already with its moronization of the average computer user. I don't think Perl should go the same way. Let's not insult the user by assuming (s)he only has two working braincells.

-- Abigail

"I think you are stoooooopid; here's a 5Mb binary..."

The issue isn't intelligence, it's how much time administrators have available to wrestle with an installation process when they're busy doing fifty billion other things. Make the installation extremely simple (and reversible) and you increase the chances that someone will actually install and use the program. Greatly. Make it difficult to install, and you increase the chances that someone along the chain of command will decide that isn't worth the hassle.

If the customer can install it without caring that it's written in Perl, it certainly isn't going to increase the popularity of Perl - because the customer doesn't even know Perl is being used.

By this logic, C and C++ must be really, really unpopular. No customer installing an application written in those languages knows that C/C++ is being used, after all...

The ability to deliver atomic, easily-installed apps would increase the popularity of Perl among the people who write the apps, not the people who use them. If a developer with the freedom to do so is picking an implementation language for an app, and one language requires delivering a bundle of modules and maybe getting the installer to do some other hand-waving, and the other language has an easy, ready-made way to shrinkwrap and deliver the app, that fact could very well sway her away from Perl if the other (dis-)advantages of the respective languages balance each other out.

Excuse me? What makes you think a binary program is easier to install than a text program? The claim wasn't that the installation of the program is easier (of course it isn't - it's still a program), the claim was that maintaining the installation of Perl is hard. And that's something I question. It's as hard as you want it to be.

By this logic, C and C++ must be really, really unpopular. No customer installing an application written in those languages knows that C/C++ is being used, after all...

Oh, I see! C is so popular because people insist of using programs written in C! That's it! Yeah, right. The popularity of C doesn't depend on the number of people installing programs because they are written in C.

The ability to deliver atomic, easily-installed apps would increase the popularity of Perl among the people who write the apps, not the people who use them.

Could you please, please tell us what's so frigging hard in installing a program written in Perl that magically disappears when it's delivered in a binary format?

-- Abigail

The ability to deliver atomic, easily-installed apps would increase the popularity of Perl among the people who write the apps, not the people who use them. If a developer with the freedom to do so is picking an implementation language for an app, and one language requires delivering a bundle of modules and maybe getting the installer to do some other hand-waving, and the other language has an easy, ready-made way to shrinkwrap and deliver the app, that fact could very well sway her away from Perl if the other (dis-)advantages of the respective languages balance each other out.

Exactly. One case at work involved a complex installation that had a master installer that would run other parts. It would have been great to write that in Perl. But, how does one run a Perl program off a CD without "installing" it or the whole Perl system first? Even using a bundling system like PerlApp had a certain amount of risk involved. Instead, we wrote that piece in InstallShield, which easily makes a self-contained single runable file that can be simply run from the CD or other location, and is known to do that well. However, it turned into a terrible mess because the language isn't at all robust or suitable for larger programs. I wanted to use Perl because of Perl the language. I could not deliver a Perl solution because of Perl the system.

—John

A preprocessor that goes through Perl 5 code and generates Perl 6 code that the 6 interpreter can read? How buggy could that be? For the near future Perl's developers will do everything twice -- write the new code, then write routines that convert old versions of Perl to the new one.

No other language that I know of uses such a model. Not the current Perl, nor Visual Basic, C, C++, Java, Oracle PL/SQL, whatever. What if the Perl 6 preprocessing model turns out to be a bad way of writing computer languages?

The idea is supposed to be that you write once, in Perl 5 let's say, and run anywhere, on Perl 6, 7, 8, 9 whatever.

Write once, run anywhere didn't work very well for Java applets. They seemed to break on every new browser/JVM combination. I hope it works better for the new improved Perl.

Maybe I will sit out this next round of Perl improvements. I still only use half the features in Perl 5.x, and I have been coding Perl for a year.