|Syntactic Confectionery Delight|
|( #3333=superdoc: print w/replies, xml )||Need Help??|
"...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"
«The Crux of the Biscuit is the Apostrophe»
In reply to Re: When to bundle Perl with your app?