# from Mark Dootson # on Monday 25 June 2007 04:38 pm: >On reflection, getting past the 'lets have a --bloat-flag' and > "Haven't got a clue" sillyness, I think you may well be right.
By "a clue", I simply mean that I expect a pp user to understand "a par is a zip archive which must contain everything your program needs" and understanding how to add modules to the list. Without being able to assume that, we have to support the "somebody told me to just run pp foo.pl" usage. Also implied is some understanding of Perl's dynamic nature. If we can assume at least a cursory glance at the manpage, then maybe the manpage needs to convey that essential information more clearly. Quite a few problems are easily diagnosed by `unzip -l foo.par`, yet they still turn up here. I get the impression that we're not making "it's a zip file" clear enough. Of course, most cases where pp doesn't "just work" can be directly attributed to Module::ScanDeps not having enough information. The simple fact is that M::SD doesn't know enough to do a better job. This is complicated by the fact that it can't know everything until runtime (and what it can learn from *running* the code still depends on which code actually runs (i.e. coverage.)) So, the very nature of Perl means the best case is "might work" unless we (bloat) package your entire computer (and network drives?). We can get "will most likely work" by packaging all of your modules and any related .so/dll/dylibs, but that's still bloat. We can do "will probably work" if we either use PPI for more accurate static scanning or run it through the perl -c phase. It would take a lot of work to make M::SD do PPI. Maybe pp should just default to prompt you: "Is it safe to run your code through the compiler? (This is likely to give a better dependency scan but might cause explosions if your BEGIN blocks do strange things.) [Yn]" Of course, that's going to break any automated tools which don't expect pp to change in that way. Maybe ppnewb/ppdwim aliases or a --guided switch for interactive mode? Hmm, probably easiest to just improve the manual and plead rtfm. I'm still hoping to get the time to get output from my test suite via Devel::TraceDeps setup as an explicit/cached "no scanning at packaging time" dependency list. That sort of approach is really the only choice for *optimal* packaging of Perl dependencies (but will only be as reliable as your test coverage.) --Eric -- "It is impossible to make anything foolproof because fools are so ingenious." --Murphy's Second Corollary --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------