Also, Webstart

The disadvantage of prepackaged bundles like eggs or par files is that maintainers have to provide one for every target machine or sometimes even distribution.

On the other side (the user side) I think perl users are accustomed to cpan, they usually see no reason to look for PARs, maybe with the exception of windows users. Why change when the current system works?

A really sore point about cpan is that it may conflict with perl packages installed by a distribution. Other than that there is nothing complicated about it, maybe only that there is no GUI (that I know of) for newbies

Ah ok, I understand more now. I guess Python people have to make it this way, that they must go through this hassle of creating personal egg files for each platform and python version for each library dependency needed and then host them on their server for automatic download because they don't have many other alternatives like we have.

I agree with all of your comments, in the end the CPAN way is much better and if I'm thinking correctly if you are providing the public with an application you can use Module::AutoInstall to provide the same CPAN automatic dependency download and installation during initial application setup, essentially the same but better than that mentioned with the eggs and Python

Eh? Then we're back to commercial solutions, perl2exe, perlapp ... oh look, ppmx again , its the egg

Sorry maybe there was a misunderstanding, apologies I meant never seeing for example an application written in Perl that you download and install and during the setup it automatically fetches PAR files of all the CPAN dependencies it needs and puts these somewhere that then when I run the application it just magically knows where and how to load these.

But later in this thread it was made clear why no one would do it this way because you would need to create .par files for each supported version of Perl and for each platform for that dependency... pain in the neck :)

Having maintained PAR for five years and written quite a large chunk of the PAR-related tools, let me tell you that it's just not true that PAR is not used for packaging large applications. People from quite a few large and well known companies have contacted me directly for (free and private, sigh) support over the years. At least one of them mentioned that he was using PAR to deploy applications to ~40k computers in the corporation.

Personally, I have packaged applications with a few hundred thousand lines and many, many CPAN modules (Perl & XS) successfully for multiple operating systems.

Is this sufficient?

Ok yes maybe you do see it in companies... I work in the open-source world and as I said have never seen this for Perl-based projects/apps/systems/servers that are publicly available.

Here's a wild thought -- isn't there a single, easy-to-use tool that will automatically download, test, and install Perl modules for a particular environment like App::Magpie does for Mageia Linux, but using something like local::lib? You can then simply copy/rsync the lib to your target machines.

If this could run in the background, find the latest versions of desired Perl modules, and log error reports somewhere it would satisfy corporate/organizational needs because groups of people who care about fast installs tend to be using the same computing environments.

Celebrate Intellectual Diversity

Here's a wild thought -- isn't there a single, easy-to-use tool that will automatically download, test, and install Perl modules for a particular environment like App::Magpie does for Mageia Linux, but using something like local::lib?

Maybe you didn't see the synopsis for local::lib, but yes, there is such a tool, and its called cpan/cpanp/cpanm, local::lib isn't required or even necessary

You can then simply copy/rsync the lib to your target machines.

If you have rsync, compile install perl in your home directory, and simply rsync the entire perl tree