# 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
---------------------------------------------------
