On 6/22/07, Chas Owens <[EMAIL PROTECTED]> wrote:
Most of the time the policy is enacted by lower-case-l lazy sysadmins
who can't be bothered to type
perl -MCPAN -e install Foo::Bar
My normal route around them is to install the module into the home
directory of the user who is going to run the script, but I have had
difficulty with this before when it comes time to move to production:
"Where is the code review for that code?". My answer of "where is the
code review for that (often open source) database install you just
did?" doesn't tend to hold the weight I wish it did. For some reason
binary blobs make some types of sysadmins feel all fuzzy and warm
inside.
so use the parrot back end and compile all the modules to bytecode.
oh, and you can merge the foreign module bytecode with the bytecode
for your application, so it's all one big happy binary file.
in fact, parrot will even provide a way to compile bytecode to a
native executable which contains parrot itself. there, now you've got
a proper binary with *zero* external requirements in the production
environment--it doesn't even need to have parrot installed.
at that point, i'd be surprised if the release engineers or sysadmins
even notice.
~jerry
