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/Test.pm or Apache/test.pm 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 > again. > > 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/Test.pm with Apache/test.pm. 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/test.pm), 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. -- best regards, randy
