Stas> 99.9% of users do *not* need to use this workaround. So that Stas> issue is moot if you ask me.
Randal> You keep saying this like you believe it. In fact, the number keeps
Randal> getting closer to 100% each time.
Randal> This is pure, fabricated *fiction*.
For me, this ends up being the sane way to do it, for the same reason I install Apache2 into a separate tree. MP2 isn't simply a collection of modules. It's an embedded interpreter with pieces that enter the Apache tree. I realize this isn't the big issue, but comparisons to other Perl "generations" don't quite match for this reason.
Randal> Four out of my five biggest customers *will* need to have both
Randal> modperl1 and modperl2 in the same Perl installation tree on their
Randal> development machines, because they'll need to start looking at how to
Randal> port their work over, and they won't want to duplicate-install all the
Randal> other modules they use into two different Perl installations on one
Randal> box.
I may be the exception, but I've done a lot of porting already and would never go about it the way you describe. An mp2 install (regardless of the solutions at hand) virtually demands a clean Perl install (usually on a clean box as well), and duplicate installs of dependency modules is typical on any migration project I do in the interest of having a sane development environment and duplicate-ability (not unlike the separate apache2 tree itself). I then introduce the code to be ported into the new environment in much the way that the mp2 docs describe. Whether users *will* port this way is debatable. But if forced, I'd say they're being forced into the preferable scenario anyhow.
I agree with Adam's points on the API, but think Stas is correct that most users will not have both "generations" installed in the same tree. The fact that mp2 is such a radical departure from mp1 is to me an argument for porting into a "clean" tree, in much the same way that the API incompatibilities are others' argument for a change of namespace. :-)
-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
