Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN

[prev] [thread] [next] [Date index for 2005/01/01]

From: Dan Brian
Subject: Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN
Date: 02:14 on 01 Jan 2005
> 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

(message missing)

Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN
merlyn (Randal L. Schwartz) 22:26 on 31 Dec 2004

Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN
Dan Brian 02:14 on 01 Jan 2005

can't locate Apache/Build.pm
Randy Kobes 21:23 on 05 Jan 2005

Re: can't locate Apache/Build.pm
Randy Kobes 17:43 on 06 Jan 2005

Re: can't locate Apache/Build.pm
Ron Savage 22:13 on 06 Jan 2005

Re: can't locate Apache/Build.pm
Randy Kobes 23:42 on 06 Jan 2005

Re: can't locate Apache/Build.pm
Ron Savage 22:49 on 07 Jan 2005

Re: can't locate Apache/Build.pm
Randy Kobes 23:07 on 07 Jan 2005

Re: can't locate Apache/Build.pm
Ron Savage 02:32 on 08 Jan 2005

Re: can't locate Apache/Build.pm
Randy Kobes 06:28 on 08 Jan 2005

Re: can't locate Apache/Build.pm
Randy Kobes 15:28 on 08 Jan 2005

Re: can't locate Apache/Build.pm
Ron Savage 00:36 on 09 Jan 2005

Re: can't locate Apache/Build.pm
Ron Savage 22:00 on 08 Jan 2005

Re: can't locate Apache/Build.pm
Geoffrey Young 23:12 on 07 Jan 2005

Re: can't locate Apache/Build.pm
Randy Kobes 06:43 on 08 Jan 2005

Generated at 12:16 on 16 Jan 2005 by mariachi v0.52