* On Thu, Apr 16 2009, James R. Leu wrote: > I must have missed the memo about PAR not being recommend. Is there a > discussion thread I can read about it?
I think this is just t0m's personal opinion. Anyway, the code for catalyst_par is very very flaky. Keep this in mind as you use it. If the PAR you produce works, it will work, and it's a good way to deploy. If it doesn't work, then some hacks are needed to get it working. I plan on improving this situation in the future, although in a somewhat roundabout way (so it's not going to be fixed next week, but maybe next year). The basic idea is to start the application to the point where it is about to serve a request, snapshot %INC, and then use that as the list of modules to bundle. This fixes most cases of lazy-loaded modules not being bundled with the PAR, but not all of them. (Another option that I have not tried is to not auto-detect which modules to load, and instead take them from the Makefile.PL. That way, if a module is not available, It's Your Faultâ„¢. You can emulate this behavior with the existing code, however.) Oh yeah, I am also thinking of ways to bundle your test suite with the PAR, and easily run them from the deployed PAR. That will alleviate many of my PAR deployment worries. (Ping me on IRC for more details, or see http://github.com/jrockway/moosex-runnable ) Regards, Jonathan Rockway -- print just => another => perl => hacker => if $,=$" _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/