in reply to Production obfuscation

I know this horse has been beaten and there is plenty of info out there
Actually, I don't think it has. As the author of Acme::EyeDrops, the only animal I'm aware of being harmed for production obfuscation is not a horse but a frolicking wombat, proposed by `/anick in 2002 to enhance "psychological obfuscation" because "surely the script dealing with super-secret FBI passwords isn't that ASCII picture of a frolicking wombat".

So, I'm want to know issues of Acme::EyeDrops in production and what liabilities I need to be aware that when converted could cause me issue
If you haven't already done so, read the "EyeDropping" section in the Acme::EyeDrops documentation and follow the advice there. As that section indicates, (a non-trivial module) has been successfully converted into 151 camels and all tests still pass. At that time, I was considering distributing the module itself in EyeDrop'ed form but decided against it not because it didn't work but because it was four times slower. Also note that if you set the PERL_SMOKE environment variable before running "make test", the test suite will automatically convert and the test suite itself into camels and run them again. Which passes. So I have fair confidence that you won't hit any serious problems with your approach and if you do, you should be able to work around them (as was done with the "eval-hostile" line in, described in the "EyeDropping" section). Having said that, it would be prudent to have a test suite for your code and to run it both before and after EyeDrop-ification.