perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: resolving Apache::Test vs. Apache::test collision
Date Thu, 08 May 2003 00:45:31 GMT
Randy Kobes wrote:
> On Tue, 6 May 2003, David Wheeler wrote:
>>On Tuesday, May 6, 2003, at 08:49  AM, Randy Kobes wrote:
>>>An upshot of this is that, when installing Apache-Test,
>>>a system file Apache/ or Apache/ should
>>>probably be unlinked before copying to the blib/ directory.
>>Yes, and hope that they don't reinstall mod_perl 1 with its Apache/test 
>>I'm beginning to think that, for all the up-front hassle of it,
>>just renaming it to Apache::Tester or Test::Apache will avoid
>>more headaches in the long run.
> That's a good point, although as Stas pointed out, it may cause
> some confusion with those already using Apache::Test.
> If one views (philosophically) Apache::Test as a major upgrade to
> Apache::test (with a different API), might it be reasonable to
> consider replacing those packages that use Apache::test with
> Apache::Test? For example, in the next mod_perl 1 release,
> require Apache-Test for the tests, and do away with Apache::test?  
> This would require rewriting the tests, which might be worth it
> anyway, as a major illustration that Apache-Test works equally
> well with mod_perl 1 (I'd volunteer to look at that, as I'm on
> one of the offending systems).
> I guess one advantage to this, recalling Stas' suggestion of
> putting the functionality of Apache::test into Apache::Test, is
> that two quite distinct test frameworks don't have to,
> officially, be supported. And it also, eventually, addresses the
> problem of installing mod_perl 1 after an Apache-Test
> installation and overwriting Apache/ with Apache/
> The downside, of course, is that mod_perl 1 is very stable, and
> so major changes like this aren't desireable. Another
> disadvantage is that there's 3rd party mod_perl 1 modules that
> use Apache::test (for example, Apache-Filter), and these would be
> affected. 
> Perhaps a compromise to the above is to just do this on Win32/Mac
> OSX (or even not changing the test framework at all in mod_perl
> 1, and just not install Apache/, and then just print out
> a warning that this is being done, and why. This wouldn't affect
> as many users, and in the Win32 world, and perhaps also on the
> Mac, I think users are used to major upgrades that aren't
> necessarily backwards compatible.

The problem with providing a replacement for Apache::test is that some people 
are going to reinstall older mod_perl versions and kill the overriden file.

In any case rewriting mp1 test suite and all 3rd party module test suites is 
not an option, since I doubt this is going to happen.

Renaming to Test::Apache will require lots of changes, including a potential 
loss of cvs history.

So it seems to me that the simplest route to take is to 
s/Apache::Test/Apache::Tester/ as suggested by David. Only one file is modified.

If there are no objections, I'll proceed with this route.

One question remains: should the package be renamed to Apache-Tester as well? 
Since people will see Apache::Test and will try to install Apache::Test in, and that won't work.

Notice that we can't put in a dummy Apache/, because it'll overwrite 
Apache/ and break mp1 test suites. But may be if we copy Apache/ 
to Apache/ as is, this will work. Though it may confuse users who will 
try to use it. It also will require to maintain the version in it and not 

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message