On 6/22/07, jerry gay <[EMAIL PROTECTED]> wrote:
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
Good point. I am still to stuck in the Perl 5 mind set.
