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