Sometimes correct operation of a Perl application depends on a specific combination of the versions of installed modules. By bundling a custom installation with your app, you can increase the probability your app will run correctly on a system other than your development machine.

Of course, it would be better to test your app on several very different systems to weed out such dependencies. And if you aspire to have your app available as a package in your favorite Linux/BSD/whatever distribution, you need to make sure it works with the default Perl installation for that distro (which is often very very old and often lacks many very useful modules).

I consider my target Perl version and installed modules part of my application, just to avoid the 'vendor changed perl installation' issue. OTOH, this is an internal system, and my application does not need to run on everything out there. That being said, on platforms like Win32, where perl does not come bundled, bundling Perl with your application removes a layer that the user needs to manage.

This really depends on whether you're working on an internal application or distributing it more widely.

When you don't have control of the target system, it's best to control your Perl environment. If you develop, test, stage, and deploy on configuration managed systems that are kept as similar as possible then feel free to distribute just the application to production.

Just to add to the other good responses here already: It also depends on what versions of Perl you test your script / application against. If you've designed your code to be very portable, then you don't need to worry too much about the environment you're running it in, except that it might need to meet a few minimum requirements (in your case, Mojolicious being installed would probably be the most important). When a new version of Perl is released, distros won't pick it up immediately, so you have some time to test your program against the new Perl version.

(If your program isn't designed to be particularly portable, the bundling suggestion and the other monks' comments apply.)

( though Mojolicious has the reputation to have only few dependencies ... so the answer correlates with the number of additional modules your app depends on )

Mojolicious has nearly no dependencies declared, i.e. perl 5.10.1 and ExtUtils::MakeMaker 0, but has many on core modules. Also Mojo has many (undeclared) suggests or recommends dependencies, which are required in an string eval.

A few weeks ago I got in the dependency hell with Mojolicious: Something working for a long time (using the dump helper in a template) threw an error. Seems that another installation of a CPAN module required an explicit minimal version of Data::Dumper. But at the time of installation Data::Dumper was broken. This took me some hours to try, diagnose, and update. Yes, if someone is paranoic against such (extremely seldom) situations, then it is a good approach. But in most cases such approaches waste resources.

Mojolicious itself might have few dependencies, but any non-trivial application that you write using it will have loads.

Yes, you're wrong. Sort of.

Disk space might as well be free these days, so you needn't worry about that. Memory is cheap too, so you shouldn't care about being able to share memory pages between invocations of the same perl binary (if you care that much about memory you shouldn't be using perl at all).

Now for the "sort of". The only problem with shipping perl with your application is that it will only work on one platform. So I ship a script that will configure and build perl and stick it in my application's directory.

"...I was told that building an entire Perl build (e.g. perlbrew) with a shipped application was the best way ...I found that concept horrific...a good thing to ship a custom Perl build?"

Mmh, more and more i tend to build Perl using perlbrew.

OK, it's a little bit more work.

But some years ago i fired up cpan to install some missing modules on OS X Server. Somewhere in my older posts i mentioned this already.

It run amok and tried to uninstall/install a few tens of modules and another version of Perl.

I forgot about the awful details but i ended up with a broken unusable production system.

So i jumped to the conclusion that it would be better to have some kind of functional user for a app - having it's own Perl environment.

Quite easy to create a user, put him in the group wheel if needed - and then fire up perlbrew.

There are so many apps that require their own user account/environment. E.g. many come with their own Java environment and their own DB.

So IMHO there is nothing wrong with this approach from a admins point of view. It's common practice.

If things go totally wrong just delete the functional user and its $HOME and start again ;-)

To me, this seems to be much easier than restoring a broken system, even on a test machine. Another good thing: put $HOME under some version control.

Just a few thoughts about this issue. Loosely based on Voronich:

"I think it's not your first rodeo"

Regards, Karl

On OS X using perlbrew is a must.

Well, as usual, “it depends.”   Perl is a very modular system ... unlike, say, PHP, it consists of a tiny language core which “uses” everything that it requires in order to do any particular thing.   One way to do this, say in a production environment, is to standardize all the systems to a known-good configuration.   Another way to do it is to bundle with the Perl app everything that this Perl app needs to run, and to place those components into an isolated directory that only this app will reference.   On the one hand, it is “wasteful.”   (But, who cares anymore?)   It is isolated, therefore very independent.

As a self-confessed “sysadmin,” you are more likely to want to set up and maintain the first scenario, rather than the second.   You will standardize the configuration of every production system, every test and build system, to the same base set of packages, instead of choosing to follow the perlbrew advice.   Neither approach is categorically right nor wrong.

In the case of Mojolicious you shouldn't worry. I have the latest running fine on Debian squeeze, Perl 5.10.1.

This sort of discussion is a little bit overdone. If you ask a developer, you should always install the latest and greatest. If you ask a sysadmin, you should install via apt-get from stable to allow automated updates.

I've got a foot in both camps, and I say that your application plus its dependencies (perl itself is a dependency) should be built as debs, which you store in your own corporate repository, which have minimal dependencies on Debian's own packages, and which install in somewhere like /opt/companyname/...

I use perlbrew in almost all cases I can. If you happen to work on Red Hat Enterprise Linux, they tend to come with an outdated version of perl. Mojolicious requires at least 5.10 because it uses some new regex features for its routing.

If the platform gets updated to a different version of Red Hat Linux, using your own via perlbrew will isolate you from the vendor changes.