Front page | perl.perl6.language |
Postings from June 2007
On 6/22/07, jerry gay <jerry.gay@gmail.com> wrote: > On 6/22/07, Chas Owens <chas.owens@gmail.com> 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.