Re: resolving Apache::Test vs. Apache::test collision
David Wheeler wrote: On Wednesday, June 18, 2003, at 07:30 AM, Stas Bekman wrote: Now just awaiting a confirmation from David and I'll put Apache::Test 1.03 on CPAN. David, if you see this before tomorrow, simpy try the latest cvs, I have already committed the needed change. Hopefully it does do the right thing for you. It does. Well done. Thanks David, posting Apache::Test to CPAN. Hopefully this post concludes this *very* long thread ;) __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
On Tue, 17 Jun 2003, Stas Bekman wrote:
[ .. ]
David, please test this patch. This version performs the
cleanup only during 'make install'. what I'm not sure about is
whether it handles correctly some weird paths when creating the
packlist. I think it should work, since nothing is passed via
shell, but goes perl-2-perl.
[ .. ]
I had problems applying the original patch to httpd-test;
manually applying it worked except for an error about
a missing string terminator in the nuke_Apache__test target
(Win32 is picky about using quotes within commands).
This diff:
===
Index: Makefile.PL
===
RCS file: /home/cvspublic/httpd-test/perl-framework/Apache-Test/Makefile.PL,v
retrieving revision 1.8
diff -u -r1.8 Makefile.PL
--- Makefile.PL 29 Apr 2003 06:37:47 - 1.8
+++ Makefile.PL 18 Jun 2003 02:38:58 -
@@ -1,16 +1,21 @@
use 5.005;
+use strict;
+
use ExtUtils::MakeMaker;
use Symbol;
use lib qw(lib);
my $VERSION;
+use File::Spec::Functions qw(catfile catdir);
use Apache::Test5005compat;
use Apache::TestMM qw(test); #enable 'make test'
+my $cleanup_packlist = .mypacklist;
+
Apache::TestMM::filter_args();
my @scripts = qw(t/TEST);
@@ -21,6 +26,8 @@
set_version();
+nuke_Apache__test();
+
WriteMakefile(
NAME = 'Apache::Test',
VERSION = $VERSION,
@@ -59,3 +66,74 @@
return $string;
}
+
+# on Case-Insensitive systems Apache/Test.pm can't coexist with
+# Apache/test.pm, since Apache::test is now deprecated (was renamed to
+# Apache/testold.pm in mod_perl 1.28, we need to find and remove any
+# occurrences of this file. CPAN authors should
+# s/Apache::test/Apache::testold/ and can either require mod_perl 1.28
+# which already carries it or simply bundle it. The best option is to
+# port the test suite to use Apache::Test which works with both
+# mod_perl generations.
+#
+# we could have done this cleanup only for case-insensitive systems,
+# but I feel that doing it for all systems, will speedup the
+# transitions from Apache::test to either Apache::Test or
+# Apache::testold.
+#
+sub nuke_Apache__test {
+
+my @convicts = ();
+foreach (@INC) {
+my $dir = catdir $_, Apache;
+next unless -d $dir;
+opendir DIR, $dir or die Cannot opendir $dir: $!\n;
+my @matches = grep /^test.pm$/, readdir DIR;
+closedir DIR;
+push @convicts, map { catfile $dir, $_ } @matches if @matches;
+}
+
+if (@convicts) {
+print EOI;
+!!! Makefile.PL has found old copies of Apache/test.pm which will
+be removed during 'make install' to prevent collisions with Apache::Test:
+
[EMAIL PROTECTED] \n, @convicts]}
+
+CPAN authors are advised to either use Apache::testold or port their
+test suite to Apache::Test which works with both mod_perl generations.
+EOI
+}
+
+open PACKLIST, $cleanup_packlist
+or die Can't open $cleanup_packlist: $!;
+print PACKLIST join , map $_\n, @convicts;
+close PACKLIST;
+}
+
+sub MY::install {
+my $self = shift;
+
+my $string = $self-MM::install(@_);
+add_dep(\$string, pure_install = 'nuke_Apache__test');
+
+$string;
+}
+
+sub MY::top_targets {
+my $self = shift;
+my $string = $self-MY::top_targets;
+
+$string .= EOF;
+
+nuke_Apache__test:
+\t\$(PERLRUN) -MExtUtils::Install -e uninstall(qq{$cleanup_packlist}, 1, 0)
+EOF
+
+$string;
+}
+
+sub add_dep {
+my($string, $targ, $add) = @_;
+$$string =~ s/($targ\s+::)/$1 $add/;
+}
=
worked for me on Win32 in uninstalling an existing test.pm in all
possible @INC locations before installing the new Test.pm.
Thanks, Stas.
--
best regards,
randy
Re: resolving Apache::Test vs. Apache::test collision
Now just awaiting a confirmation from David and I'll put Apache::Test 1.03 on CPAN. David, if you see this before tomorrow, simpy try the latest cvs, I have already committed the needed change. Hopefully it does do the right thing for you. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
On Wednesday, June 18, 2003, at 07:30 AM, Stas Bekman wrote: Now just awaiting a confirmation from David and I'll put Apache::Test 1.03 on CPAN. David, if you see this before tomorrow, simpy try the latest cvs, I have already committed the needed change. Hopefully it does do the right thing for you. It does. Well done. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
David Wheeler wrote: On Monday, June 16, 2003, at 02:42 AM, Stas Bekman wrote: OK, here is the patch that nukes Apache/test.pm. Please test it on case-insensitive systems (if you don't have Apache/test.pm, please add it just to test). Once you confirm that it works, I release Apache::Test 1.03, so we can go ahead with the new libapreq release. Applied to CVS copy. If this is what you mean, it should work: mercury% perl Makefile.PL generating script t/TEST Makefile.PL has found old copies of Apache/test.pm which will be removed to prevent collisions with Apache::Test. CPAN authors are advised to either use Apache::testold or port their test suite to Apache::Test which works with both mod_perl generations. unlink /usr/local/lib/perl5/site_perl/5.8.0/darwin/Apache/test.pm !!! Failed to delete /usr/local/lib/perl5/site_perl/5.8.0/darwin/Apache/test.pm, please make sure to delete /usr/local/lib/perl5/site_perl/5.8.0/darwin/Apache/test.pm at Makefile.PL line 106. Checking if your kit is complete... Looks good Writing Makefile for Apache::Test So I deleted /usr/local/lib/perl5/site_perl/5.8.0/darwin/Apache/test.pm and all is well. Any idea why has it failed to delete the file? I've copied the code from forceunlink sub in MakeMaker (which is called on UNINST=1), it changes the mode to 0666 and then attempts to delete the file. Gonna try to carve out some time this week to port MasonX::ApacheHandler::WithCallbacks to Apache::Test :-) Cool! __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
On Monday, June 16, 2003, at 08:02 PM, Stas Bekman wrote: Any idea why has it failed to delete the file? I've copied the code from forceunlink sub in MakeMaker (which is called on UNINST=1), it changes the mode to 0666 and then attempts to delete the file. Because I ran it as a non-root user. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
Stas Bekman wrote:
David Wheeler wrote:
On Monday, June 16, 2003, at 08:02 PM, Stas Bekman wrote:
Any idea why has it failed to delete the file? I've copied the code
from forceunlink sub in MakeMaker (which is called on UNINST=1), it
changes the mode to 0666 and then attempts to delete the file.
Because I ran it as a non-root user.
This makes sense :) so it doesn't fit the idiom:
% perl Makefile.PL
% make
% make test
% su
% make install
in that case we need to override the 'make install' target to delete the
files. instead of doind that during 'perl Makefile.PL'.
David, please test this patch. This version performs the cleanup only during
'make install'. what I'm not sure about is whether it handles correctly some
weird paths when creating the packlist. I think it should work, since nothing
is passed via shell, but goes perl-2-perl.
Index: Makefile.PL
===
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/Makefile.PL,v
retrieving revision 1.8
diff -u -r1.8 Makefile.PL
--- Makefile.PL 29 Apr 2003 06:37:47 - 1.8
+++ Makefile.PL 17 Jun 2003 02:51:17 -
@@ -1,5 +1,7 @@
use 5.005;
+use strict;
+
use ExtUtils::MakeMaker;
use Symbol;
@@ -7,10 +9,14 @@
my $VERSION;
+use File::Spec::Functions qw(catfile catdir);
+
use Apache::Test5005compat;
use Apache::TestMM qw(test); #enable 'make test'
+my $cleanup_packlist = .mypacklist;
+
Apache::TestMM::filter_args();
my @scripts = qw(t/TEST);
@@ -21,6 +27,8 @@
set_version();
+nuke_Apache__test();
+
WriteMakefile(
NAME = 'Apache::Test',
VERSION = $VERSION,
@@ -59,3 +67,74 @@
return $string;
}
+
+# on Case-Insensitive systems Apache/Test.pm can't coexist with
+# Apache/test.pm, since Apache::test is now deprecated (was renamed to
+# Apache/testold.pm in mod_perl 1.28, we need to find and remove any
+# occurrences of this file. CPAN authors should
+# s/Apache::test/Apache::testold/ and can either require mod_perl 1.28
+# which already carries it or simply bundle it. The best option is to
+# port the test suite to use Apache::Test which works with both
+# mod_perl generations.
+#
+# we could have done this cleanup only for case-insensitive systems,
+# but I feel that doing it for all systems, will speedup the
+# transitions from Apache::test to either Apache::Test or
+# Apache::testold.
+#
+sub nuke_Apache__test {
+
+my @convicts = ();
+foreach (@INC) {
+my $dir = catdir $_, Apache;
+next unless -d $dir;
+opendir DIR, $dir or die Cannot opendir $dir: $!\n;
+my @matches = grep /^test.pm$/, readdir DIR;
+closedir DIR;
+push @convicts, map { catfile $dir, $_ } @matches if @matches;
+}
+
+if (@convicts) {
+print EOI;
+!!! Makefile.PL has found old copies of Apache/test.pm which will
+be removed during 'make install' to prevent collisions with Apache::Test:
+
[EMAIL PROTECTED] \n, @convicts]}
+
+CPAN authors are advised to either use Apache::testold or port their
+test suite to Apache::Test which works with both mod_perl generations.
+EOI
+}
+
+open PACKLIST, $cleanup_packlist
+or die Can't open $cleanup_packlist: $!;
+print PACKLIST join , map $_\n, @convicts;
+close PACKLIST;
+}
+
+sub MY::install {
+my $self = shift;
+
+my $string = $self-MM::install(@_);
+add_dep(\$string, pure_install = 'nuke_Apache__test');
+
+$string;
+}
+
+sub MY::top_targets {
+my $self = shift;
+my $string = $self-MY::top_targets;
+
+$string .= EOF;
+
+nuke_Apache__test:
+\t\$(PERLRUN) -MExtUtils::Install -e 'uninstall($cleanup_packlist, 1, 0)'
+EOF
+
+$string;
+}
+
+sub add_dep {
+my($string, $targ, $add) = @_;
+$$string =~ s/($targ\s+::)/$1 $add/;
+}
Re: resolving Apache::Test vs. Apache::test collision
OK, here is the patch that nukes Apache/test.pm. Please test it on
case-insensitive systems (if you don't have Apache/test.pm, please add it just
to test). Once you confirm that it works, I release Apache::Test 1.03, so we
can go ahead with the new libapreq release.
Index: Changes
===
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/Changes,v
retrieving revision 1.26
diff -u -r1.26 Changes
--- Changes 6 Jun 2003 01:46:13 - 1.26
+++ Changes 16 Jun 2003 06:40:03 -
@@ -8,6 +8,11 @@
=item 1.03-dev -
+Instrumented Makefile.PL to unconditionally remove any old
+pre-installed occurrences of Apache/test.pm, which has been renamed to
+Apache/testold.pm in mod_perl 1.28 to avoid collisions with
+Apache/Test.pm on case-insensitive systems. [Stas]
+
Apache::TestClient now handles correctly responses with no body and
its response header() method is no longer case-sensitive [Stas]
Index: Makefile.PL
===
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/Makefile.PL,v
retrieving revision 1.8
diff -u -r1.8 Makefile.PL
--- Makefile.PL 29 Apr 2003 06:37:47 - 1.8
+++ Makefile.PL 16 Jun 2003 06:40:03 -
@@ -7,6 +7,8 @@
my $VERSION;
+use File::Spec::Functions qw(catfile catdir);
+
use Apache::Test5005compat;
use Apache::TestMM qw(test); #enable 'make test'
@@ -21,6 +23,8 @@
set_version();
+nuke_Apache__test();
+
WriteMakefile(
NAME = 'Apache::Test',
VERSION = $VERSION,
@@ -59,3 +63,47 @@
return $string;
}
+
+# on Case-Insensitive systems Apache/Test.pm can't coexist with
+# Apache/test.pm, since Apache::test is now deprecated (was renamed to
+# Apache/testold.pm in mod_perl 1.28, we need to find and remove any
+# occurrences of this file. CPAN authors should
+# s/Apache::test/Apache::testold/ and can either require mod_perl 1.28
+# which already carries it or simply bundle it. The best option is to
+# port the test suite to use Apache::Test which works with both
+# mod_perl generations.
+#
+# we could have done this cleanup only for case-insensitive systems,
+# but I feel that doing it for all systems, will speedup the
+# transitions from Apache::test to either Apache::Test or
+# Apache::testold.
+#
+sub nuke_Apache__test {
+
+my @convicts = ();
+foreach (@INC) {
+my $dir = catdir $_, Apache;
+next unless -d $dir;
+opendir DIR, $dir or die Cannot opendir $dir: $!\n;
+my @matches = grep /^test.pm$/, readdir DIR;
+closedir DIR;
+push @convicts, map { catfile $dir, $_ } @matches if @matches;
+}
+
+if (@convicts) {
+print EOI;
+Makefile.PL has found old copies of Apache/test.pm which will
+be removed to prevent collisions with Apache::Test.
+
+CPAN authors are advised to either use Apache::testold or port their
+test suite to Apache::Test which works with both mod_perl generations.
+EOI
+}
+
+for (@convicts) {
+print unlink $_\n;
+chmod 0666, $_;
+unlink $_
+or warn !!! Failed to delete $_, please make sure to delete $_;
+}
+}
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
On Monday, June 16, 2003, at 02:42 AM, Stas Bekman wrote: OK, here is the patch that nukes Apache/test.pm. Please test it on case-insensitive systems (if you don't have Apache/test.pm, please add it just to test). Once you confirm that it works, I release Apache::Test 1.03, so we can go ahead with the new libapreq release. Applied to CVS copy. If this is what you mean, it should work: mercury% perl Makefile.PL generating script t/TEST Makefile.PL has found old copies of Apache/test.pm which will be removed to prevent collisions with Apache::Test. CPAN authors are advised to either use Apache::testold or port their test suite to Apache::Test which works with both mod_perl generations. unlink /usr/local/lib/perl5/site_perl/5.8.0/darwin/Apache/test.pm !!! Failed to delete /usr/local/lib/perl5/site_perl/5.8.0/darwin/Apache/test.pm, please make sure to delete /usr/local/lib/perl5/site_perl/5.8.0/darwin/Apache/test.pm at Makefile.PL line 106. Checking if your kit is complete... Looks good Writing Makefile for Apache::Test So I deleted /usr/local/lib/perl5/site_perl/5.8.0/darwin/Apache/test.pm and all is well. Gonna try to carve out some time this week to port MasonX::ApacheHandler::WithCallbacks to Apache::Test :-) Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
---BeginMessage---
-- justin ]
On Monday, May 19, 2003, at 06:41 PM, Stas Bekman wrote:
So we need to figure out how to enforce UNINST the old Apache/test.pm
if any.
For example we could adjust MY::install to unlink it, without messing
with UNINST=1, though the latter will be the simplest.
Sounds okay to me. I don't know much about the MY:: stuff in
Makefile.PL.
and I haven't tried any tests that use Apache::test using the new one.
I think Geoff's Apache::Clean for mp1 uses it. So does older libapreq.
I just tested it with MasonX::ApacheHandler::WithCallbacks, and it
looks like it works pretty well. It failed different tests than it did
with the old Apache::test that I have in the distribution (which I
didn't know was failing any!), but that's likely to be some error on my
part or due to a change in Apache::test rather than a flaw in the
approach you're taking to the case-insensitive problem. So I would say
that it works pretty well.
in our case it's then much simpler. Since we don't have
lib/Apache/test.pm, we can simply test:
my $is_case_insensitive = -e catfile qw(lib Apache test.pm);
Ah, yes, of course. So there _is_ a simple way to test for it!
Other than the convenience, Apache::Test is used in at least two books
('mod_perl cookbook', and most likely 'practical mod_perl' too. So
it's a bummer to have these in Errata if we can find an acceptible
workaround.
It's a trade-off. Either well-documented errata for those two books, or
potential support issues going forward. But you already know that. Your
call.
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Kineticode. Setting knowledge in motion.[sm]
---End Message---
Re: resolving Apache::Test vs. Apache::test collision
---BeginMessage--- -- justin ] On Monday, May 19, 2003, at 05:08 PM, Stas Bekman wrote: That's right. Let's try this next: I've attached a new patch, which moves the creation of lib/Apache/test.pm into a Makefile.PL. On case-insensitive systems it'll overwrite lib/Apache/Test.pm. That appears to work, but it didn't uninstall the old test.pm, and I haven't tried any tests that use Apache::test using the new one. I wish there was a simple test to figure out whether a filesystem is case-insensitive. I think that Perl itself does something like this: use File::Spec::Functions qw(catfile); my $file = catfile 't', 'TestTest'; open F, $file or die Cannot open $file: $!; close F; my $is_case_insensitive = -e catfile 't', 'testtest'; unlink $file; Also could it possible that under the same OS one partition is case-insensitive while the other is not? If so, what happens if the package is built on one but the target is the other? Oh, fer cryin' out loud, I don't know. Rename it Apache::Tester and don't worry about it, I say. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm] ---End Message---
Re: resolving Apache::Test vs. Apache::test collision
---BeginMessage--- [ This message is resent on behalf of David Wheeler [EMAIL PROTECTED]. -- justin ] On Monday, May 19, 2003, at 03:43 PM, Stas Bekman wrote: That's the trick. Each of these files contains both Apache::test and Apache::Test (do you see that each has require() called twice?). So it doesn't matter which one gets overwritten. Give it a try. But you can't have them both in the tarball, because users will get an error when they unpack them and will send you bug reports. Here's what happens when I apply the patch, just to give you an idea. mercury% patch -p0 ~/Desktop/patch The next patch would create the file Apache-Test/lib/Apache/test.pm, which already exists! Assume -R? [n] Apply anyway? [n] y patching file Apache-Test/lib/Apache/test.pm Patch attempted to create file Apache-Test/lib/Apache/test.pm, which already exists. Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file Apache-Test/lib/Apache/test.pm.rej patching file Apache-Test/lib/Apache/test_mp1.pm patching file Apache-Test/lib/Apache/TestReal.pm patching file Apache-Test/lib/Apache/Test.pm David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm] ---End Message---
Re: resolving Apache::Test vs. Apache::test collision
---BeginMessage--- [ This message is resent on behalf of David Wheeler [EMAIL PROTECTED]. -- justin ] On Tuesday, May 13, 2003, at 08:08 PM, Stas Bekman wrote: If an old mod_perl 1.0 is installed and it overrides Apache::Test, Makefile.PL will simply fail to satisfy the requirement of a specific version (because Apache::test's version is smaller than Apache::Test's). Not sure I follow you here. CPAN.pm checks for such dependencies, but Makefile.PL, AFAIK, does not. And CPANPLUS doesn't work right, FWIW, because Apache::test has no version number at all, which CPANPLUS (mistakenly) assumes means that it's up to date. However taking again this track of overriding test.pm, we may still have a problem in the following situation: root installs mod_perl 1.27 system-wide, user installs Apache::Test locally (can't unlink Apache/test.pm), this can be a problem if user's @INC are added after the system-wide ones. But that would be silly, isn't it? Most likely, yes. If we are sticking with this track, we need to figure out the way to make sure that Apache/test.pm is nuked. David, if Apache-Test includes Apache/test.pm and Apache/Test.pm is it ensured that any other occurance of Apache/test.pm will be nuked? I think only if UNINST=1. HTH, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm] ---End Message---
Re: resolving Apache::Test vs. Apache::test collision
---BeginMessage--- -- justin ] On Thursday, May 8, 2003, at 05:44 PM, Stas Bekman wrote: 1) Integrate test.pm in Test.pm. I think we should bundle Apache::Test with future versions of mod_perl to make the maintenance simple and remove the original Apache::test from it. 2) Rename Apache::Test to Apache::Tester (or else) to resolve the collision. Rename the distro Apache-Test to Apache-TestHarness (or else) to avoid confusion. Looks like if we can provide a clean implementation of (1) that's would be the best solution. Randy says that it shouldn't be a problem with winFU. If David says that it's cool with MacOSX, let's try to take this route then. It's much more likely that someone would install 1.27 over an Apache::Test installation on Mac OS X than it is on Win32, apparently. But if you were to release 1.28 with the new integrated Apache::Test, it probably wouldn't be too much of a problem. You might want to post a quick query to macosx@perl.org to get a general feel from the Mac OS X Perl community. HTH, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm] ---End Message---
Re: resolving Apache::Test vs. Apache::test collision
---BeginMessage---
[ This message is resent on behalf of Philippe M. Chiasson
[EMAIL PROTECTED]. -- justin ]
On Tue, 2003-05-13 at 07:36, Stas Bekman wrote:
Geoffrey Young wrote:
I actually like Apache::TestPlan, it's most of the functionality that
this module provides. but there are a few subs that are not. May be
this other functionality should move elsewhere.
given that almost all of the functions from the various Test* packages
are exported by default and almost nobody specifies an import list
currently with Apache::Test, I wouldn't worry too much about shuffling
stuff around later after the immediate problem has been fixed.
This is what I see now as the simplest solution at all fronts:
1) keep the distro name Apache-Test.
2) s|Apache/Test.pm|Apache/TestPlan.pm|
3) contents of Apache/TestPlan.pm:
package Apache::Test;
$Apache::Test::VERSION =3D '1.02';
package Apache::TestPlan;
# what was previously Apache::Test code follows
I decided to nevertheless plug these two lines in:
package Apache::Test;
$Apache::Test::VERSION =3D '1.02';
so that CPAN will still index Apache::Test, and we can still tell CPAN.pm to
install Apache::Test, same for dependencies list. Also that's where we
maintain the distro's version.
Usage-wise, the only change you have to do is this:
perl -pi -e 's|use Apache::Test([\s;])|use Apache::TestPlan$1|' files
Is everybody happy with that solution?
[late on this thread, but nontheless] I also like it
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-- =
-
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634=
E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3=
A5A5
Q: It is impossible to make anything foolproof because fools are so ingenio=
us.
perl -e'$$=3D\${gozer};{$_=3Dunpack(P7,pack(L,$$));/^JAm_pH\n$/print||$$+=
+redo}'
--=-16Hpeuu7KHwOm+VqGGS3
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQA+wLCfyzKhB4jDpaURAusVAJ9PcjA/K65PlieSZfIN26xNIq/e9ACcC+fQ
p0oiGEqYX8/JEYzUo1gs5b4=
=OPin
-END PGP SIGNATURE-
--=-16Hpeuu7KHwOm+VqGGS3--
---End Message---
Re: resolving Apache::Test vs. Apache::test collision
---BeginMessage--- -- justin ] On Tuesday, May 6, 2003, at 10:40 AM, Randy Kobes wrote: 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. No more so than the Apache::TestLoad solution, and probably less. 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). Even if you did port all the tests in mp1 to Apache::Test, we'd still have the problem of someone installing Apache::Test from CPAN, and then installing mod_perl 1.27 or earlier and thus restoring Apache::test. Lots of organizations are conservative, and wary of upgrading to a new release. 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. Exactly. 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. Right, although I think many of them include Apache::test in t/lib (I know mine does). 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. It just seems cleaner to me, at this point, to go with a whole new name and not have to deal with the _possibility_ of something like this leading to confusion. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm] ---End Message---
Re: resolving Apache::Test vs. Apache::test collision
---BeginMessage--- [ This message is resent on behalf of David Wheeler [EMAIL PROTECTED]. -- justin ] On Monday, May 5, 2003, at 07:34 PM, Stas Bekman wrote: I don't think this will be robust enough, since vendors tend to do things in their own subtle ways. It's probably much better to explicitly search @INC, rather than relying on INSTALLVENDORARCH. Hrm, yes, I guess you're right. I was thinking that that would put it wherever mp1's make install put it, but vendors may have done all sorts of kookie things with it. p.s. the Apache/test.pm is quite big but should be ok if it's never be modified, which I hope is the case... Isn't Ken Williams the maintainer? David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm] ---End Message---
Re: resolving Apache::Test vs. Apache::test collision
---BeginMessage---
[ This message is resent on behalf of James G Smith [EMAIL PROTECTED].
-- justin ]
Stas Bekman [EMAIL PROTECTED] wrote:
We have a problem with using the Apache::Test name, more correctly we have a
problem with using the Apache/Test.pm filename. On platforms with
case-insentive filesystems (winFU, Mac OS X) if mod_perl 1.x is installed,
there is Apache/test.pm (notice the lower case 't'). So when you say 'use
Apache::Test' it loads Apache::test. Boom, nothing works.
There are several routes we can take to resolve this problem:
1. rename Apache::Test to something else. David Wheeler has proposed to use
Apache::Tester (or even swap the sides: Test::Apache).
As much work as it would require at this point (going through and
changing all the package names, renaming files, munging CVS), I think
Test::Apache would fit in better.
What convinced me of this was a look at my test code. At the top, ignoring
the code to test for availability, I basically have (under the new name):
use Test::Apache qw(plan have ok skip);
use Test::Apache::Request qw(GET);
plan tests = $some_number, have 'LWP';
# rest of tests here
__END__
In my non-Apache modules, I have:
use Test::More;
plan tests = $some_number;
# rest of tests here
__END__
There's a nice symmetry here.
Of course, I had to go and try combining the two :) They seem to
work. I am able to use Test::More to plan and report testing while I
use Apache::TestRequest to do the fetching. This undercuts a little
the argument for Test::Apache being the better name. We still need
the Apache::TestRequest version of GET because it knows where the
test server is.
use Test::More;
BEGIN {
eval {
require Apache::TestRequest;
Apache::TestRequest - import(qw(GET));
};
}
my @required = qw(
Apache::Test
Apache::TestRequest
DBD::CSV
HTML::Mason
LWP
);
my @unavailable;
if(@unavailable = grep { ! eval require $_ } @required) {
plan skip_all = The following modules are unavailable:
. join( , @unavailable);
exit 0;
}
plan tests = 1;
my $res = GET /mason/test1.html;
ok $res-content eq '[This is a Mason Page]
';
exit 0;
__END__
--
James Smith [EMAIL PROTECTED], 979-862-3725
Texas AM CIS Operating Systems Group, Unix
---End Message---
Re: resolving Apache::Test vs. Apache::test collision
Randy Kobes wrote: On Thu, 22 May 2003, Randy Kobes wrote: On Thu, 22 May 2003, Stas Bekman wrote: [ ... ] It'd be very helpful if somebody could do a bit of processing of CPAN and figure who uses Apache::test and compile a list of their email addresses. Here's a list of packages that have Apache::test in their Makefile.PL PREREQ_PMs, or otherwise require by some means Apache::test - this was extracted from some indices used in our CPAN search engine, so may be incomplete. [ ... ] Just to add to that - this list was those packages that explicitly mention Apache::test in their Makefile.PLs as being needed to build. There may be other packages that use Apache::test but specify it indirectly via something like, eg, mod_perl = 1 or Apache::src in the PREREQ_PM, since Apache::test would be included in the distribution containing these modules. To get an accurate list of those that explicitly use Apache::test one would have to go through and build all packages that use mod_perl (I could put together a list of those), for which there's about 124. Perhaps just mailing all these authors would be simplest, and let them decide if the change would affect them. Fantastic, Randy! There are very few as expected. Can we simply grep for Apache::test in all files (not only Makefile.PL) and then 'find . |grep Apache/test.pm' to exclude those who bundle the package? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
On Thu, 22 May 2003, Stas Bekman wrote: [ ... ] So is everybody happy with this solution? (rename Apache/test.pm with Apache/testold.pm). So we can give Geoff a green light to publish his article? Sounds good ... It'd be very helpful if somebody could do a bit of processing of CPAN and figure who uses Apache::test and compile a list of their email addresses. Here's a list of packages that have Apache::test in their Makefile.PL PREREQ_PMs, or otherwise require by some means Apache::test - this was extracted from some indices used in our CPAN search engine, so may be incomplete. The email addresses could be [EMAIL PROTECTED] === M/MA/MAUNDER/Apache-AppCluster-0.02.tar.gz M/MS/MSCHOUT/Apache-AuthCookie-3.04.tar.gz K/KW/KWILLIAMS/Apache-Compress-1.003.tar.gz J/JI/JIMW/libapreq-1.1.tar.gz B/BO/BORISZ/Apache-PageKit-1.11.tar.gz K/KW/KWILLIAMS/Apache-SSI-2.17.tar.gz K/KW/KWILLIAMS/Apache-Filter-1.022.tar.gz R/RK/RKITOVER/Apache-GDGraph-0.96.tar.gz N/NB/NBYRD/Apache-PAR-0.12.tar.gz S/ST/STAS/Apache-Peek-1.01.tar.gz E/EN/ENRYS/Apache-SessionManager-0.04.tar.gz D/DW/DWHEELER/MasonX-ApacheHandler-WithCallbacks-0.95.tar.gz D/DR/DROLSKY/MasonX-Request-WithApacheSession-0.21.tar.gz = -- best regards, randy
Re: resolving Apache::Test vs. Apache::test collision
On Thu, 22 May 2003, Randy Kobes wrote: On Thu, 22 May 2003, Stas Bekman wrote: [ ... ] It'd be very helpful if somebody could do a bit of processing of CPAN and figure who uses Apache::test and compile a list of their email addresses. Here's a list of packages that have Apache::test in their Makefile.PL PREREQ_PMs, or otherwise require by some means Apache::test - this was extracted from some indices used in our CPAN search engine, so may be incomplete. [ ... ] Just to add to that - this list was those packages that explicitly mention Apache::test in their Makefile.PLs as being needed to build. There may be other packages that use Apache::test but specify it indirectly via something like, eg, mod_perl = 1 or Apache::src in the PREREQ_PM, since Apache::test would be included in the distribution containing these modules. To get an accurate list of those that explicitly use Apache::test one would have to go through and build all packages that use mod_perl (I could put together a list of those), for which there's about 124. Perhaps just mailing all these authors would be simplest, and let them decide if the change would affect them. -- best regards, randy
Re: resolving Apache::Test vs. Apache::test collision
David Wheeler wrote:
On Tuesday, May 13, 2003, at 09:11 PM, Stas Bekman wrote:
so that bug should be fixed in CPANPLUS, in any case new Apache/test
will have a $VERSION
Yes. I sent them a patch. We'll see if they apply it.
So we probably should check whether UNINST=1 is on, and if not (and if
we find another test.pm in @INC) die telling users to set it on.
Yes.
I've attached something that might work (apply against the current
mod_perl 2.0 cvs). I've moved the real Apache::Test and Apache::test
into different files. And replaced them with:
Apache-Test/lib/Apache/test.pm
-
# this is a workaround for a collision we have on the case-insensitive
# platforms which may have Apache/test.pm from mod_perl 1.0
# installed.
require Apache::TestReal;
# this is a workaround for ExtUtils::MakeMaker::parse_version
$VERSION = do { require Apache::test_mp1; $Apache::test::VERSION };
1;
-
and:
Apache-Test/lib/Apache/test.pm
-
# this is a workaround for a collision we have on the case-insensitive
# platforms which may have Apache/test.pm from mod_perl 1.0
# installed.
require Apache::test_mp1;
# this is a workaround for ExtUtils::MakeMaker::parse_version
$VERSION = do { require Apache::TestReal; $Apache::Test::VERSION; };
1;
-
I'm sure you meant those to be test.pm and Test.pm, since that's
what's in the patch.
Ooops, of course. The first one is Test.pm. The patch is correct.
However, this won't work, because of course on
case-insensitive file systems, you can't have test.pm and Test.pm in
the same directory. If you put them into different directories, it might
work. But then you'd also have to put them into different directories in
@INC, too. :-(
Sorry to bring bad news.
That's the trick. Each of these files contains both Apache::test and
Apache::Test (do you see that each has require() called twice?). So it doesn't
matter which one gets overwritten. Give it a try.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
David Wheeler wrote: On Monday, May 19, 2003, at 03:43 PM, Stas Bekman wrote: That's the trick. Each of these files contains both Apache::test and Apache::Test (do you see that each has require() called twice?). So it doesn't matter which one gets overwritten. Give it a try. But you can't have them both in the tarball, because users will get an error when they unpack them and will send you bug reports. Here's what happens when I apply the patch, just to give you an idea. mercury% patch -p0 ~/Desktop/patch The next patch would create the file Apache-Test/lib/Apache/test.pm, which already exists! Assume -R? [n] Apply anyway? [n] y patching file Apache-Test/lib/Apache/test.pm Patch attempted to create file Apache-Test/lib/Apache/test.pm, which already exists. Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file Apache-Test/lib/Apache/test.pm.rej patching file Apache-Test/lib/Apache/test_mp1.pm patching file Apache-Test/lib/Apache/TestReal.pm patching file Apache-Test/lib/Apache/Test.pm That's right. Let's try this next: I've attached a new patch, which moves the creation of lib/Apache/test.pm into a Makefile.PL. On case-insensitive systems it'll overwrite lib/Apache/Test.pm. I wish there was a simple test to figure out whether a filesystem is case-insensitive. Also could it possible that under the same OS one partition is case-insensitive while the other is not? If so, what happens if the package is built on one but the target is the other? Thanks David for testing! __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com diff Description: application/java-vm
Re: resolving Apache::Test vs. Apache::test collision
David Wheeler wrote:
On Monday, May 19, 2003, at 05:08 PM, Stas Bekman wrote:
That's right. Let's try this next: I've attached a new patch, which
moves the creation of lib/Apache/test.pm into a Makefile.PL. On
case-insensitive systems it'll overwrite lib/Apache/Test.pm.
That appears to work, but it didn't uninstall the old test.pm,
So we need to figure out how to enforce UNINST the old Apache/test.pm if
any.
For example we could adjust MY::install to unlink it, without messing with
UNINST=1, though the latter will be the simplest.
and I
haven't tried any tests that use Apache::test using the new one.
I think Geoff's Apache::Clean for mp1 uses it. So does older libapreq.
I wish there was a simple test to figure out whether a filesystem is
case-insensitive.
I think that Perl itself does something like this:
use File::Spec::Functions qw(catfile);
my $file = catfile 't', 'TestTest';
open F, $file or die Cannot open $file: $!;
close F;
my $is_case_insensitive = -e catfile 't', 'testtest';
unlink $file;
in our case it's then much simpler. Since we don't have lib/Apache/test.pm, we
can simply test:
my $is_case_insensitive = -e catfile qw(lib Apache test.pm);
Also could it possible that under the same OS one partition is
case-insensitive while the other is not? If so, what happens if the
package is built on one but the target is the other?
Oh, fer cryin' out loud, I don't know. Rename it Apache::Tester and
don't worry about it, I say.
Other than the convenience, Apache::Test is used in at least two books
('mod_perl cookbook', and most likely 'practical mod_perl' too. So it's a
bummer to have these in Errata if we can find an acceptible workaround.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
David Wheeler wrote:
On Monday, May 19, 2003, at 06:41 PM, Stas Bekman wrote:
So we need to figure out how to enforce UNINST the old Apache/test.pm
if any.
For example we could adjust MY::install to unlink it, without messing
with UNINST=1, though the latter will be the simplest.
Sounds okay to me. I don't know much about the MY:: stuff in Makefile.PL.
and I haven't tried any tests that use Apache::test using the new one.
I think Geoff's Apache::Clean for mp1 uses it. So does older libapreq.
I just tested it with MasonX::ApacheHandler::WithCallbacks, and it looks
like it works pretty well. It failed different tests than it did with
the old Apache::test that I have in the distribution (which I didn't
know was failing any!), but that's likely to be some error on my part or
due to a change in Apache::test rather than a flaw in the approach
you're taking to the case-insensitive problem. So I would say that it
works pretty well.
Cool
in our case it's then much simpler. Since we don't have
lib/Apache/test.pm, we can simply test:
my $is_case_insensitive = -e catfile qw(lib Apache test.pm);
Ah, yes, of course. So there _is_ a simple way to test for it!
if it works, then yes!
Other than the convenience, Apache::Test is used in at least two books
('mod_perl cookbook', and most likely 'practical mod_perl' too. So
it's a bummer to have these in Errata if we can find an acceptible
workaround.
It's a trade-off. Either well-documented errata for those two books, or
potential support issues going forward. But you already know that. Your
call.
Sigh :( I truly don't know how to handle that so we have zero hassle in the
future.
Here is a fresh suggestion, based on our ability to time travel. Instead of
solving the Apache::Test problem. Let's solve the Apache::test problem.
in-core 1.28:
- rename Apache/test.pm with Apache/testold.pm in mod_perl-1.x, so internal
tests work just fine (no problems here).
3rd party modules:
- s/Apache::test/Apache::testold/ and
- require 1.28
- or bundle Apache/testold.pm locally
I think there are very few 3rd party modules that use Apache::test, so we can
hunt those down and ask their authors to re-release their modules. Even if
it'll take a while for this to happen, eventually no-one will use Apache::test.
And voila problem solved.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
David Wheeler wrote: On Monday, May 19, 2003, at 07:18 PM, Stas Bekman wrote: my $is_case_insensitive = -e catfile qw(lib Apache test.pm); Ah, yes, of course. So there _is_ a simple way to test for it! if it works, then yes! It works: % perl -e 'print -e lib/Apache/test.pm ? insensitive\n : sensitive\n' insensitive Thanks! Sigh :( I truly don't know how to handle that so we have zero hassle in the future. How do the various book authors feel about having this and an Erratum? I suppose that we can still fix 'practical mod_perl' but it should get into the print any day now. Dunno about Geoff. Here is a fresh suggestion, based on our ability to time travel. Instead of solving the Apache::Test problem. Let's solve the Apache::test problem. in-core 1.28: - rename Apache/test.pm with Apache/testold.pm in mod_perl-1.x, so internal tests work just fine (no problems here). 3rd party modules: - s/Apache::test/Apache::testold/ and - require 1.28 - or bundle Apache/testold.pm locally I think there are very few 3rd party modules that use Apache::test, so we can hunt those down and ask their authors to re-release their modules. Even if it'll take a while for this to happen, eventually no-one will use Apache::test. And voila problem solved. I think there are quite a lot of them: http://search.cpan.org/search?query=Apache::testmode=all But IIRC, most have Apache::test in their distros, and since use Cuse lib unshifts directory names onto the front of @INC, in most cases it should just continue to work. That's a wrong check. It simply searches for any module having 'test' in its package name. One has to download and scan the code. At any rate, you'll still have the problem of users installing mod_perl 1.27 after installing Apache::Test. Not really, assuming that CPANPLUS if fixed, modules wanting to use Apache::Test will require Apache::Test = 1.03 or so and then it'll be re-installed again. The only problem is with those 1.x 3rd party modules, but they will updated to 'require Apache::testold', which we can distribute in Apache-Test. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Moreover, since now we know how to test for case-insensitive fs, we can copy Apache/testold.pm to Apache/test.pm on case-sensitive platforms which singles OSX as the only potentially problematic platform and only for 3rd party modules, which will be encouraged to rename s/Apache::test/Apache::testold/ I guess better: s/Apache::test/Apache::test_mp1/ __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
The only problem is with those 1.x 3rd party modules, but they will updated to 'require Apache::testold', which we can distribute in Apache-Test. Ah, but as I said, if they have Apache::test in their distros (as in fact does MasonX::ApacheHandler::WithCallbacks and, IIRC, HTML::Mason), it still shouldn't be an issue. As long as they hide it from MakeMaker so it won't attempt to install it, which will just cause an inconvenience to its users. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
David Wheeler wrote:
On Monday, May 19, 2003, at 07:57 PM, Stas Bekman wrote:
As long as they hide it from MakeMaker so it won't attempt to install
it, which will just cause an inconvenience to its users.
Of course. Mine is in t/lib, as is Mason's, I believe.
And here is a patch that will try to alert users to remove old Apache/test.pm
if any. Probably not very useful as most will miss the warnings, but we can
always say, you have been warned ;)
I'm just not sure that it's a good idea to silently nuke any files at all.
Index: Apache-Test/Makefile.PL
===
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/Makefile.PL,v
retrieving revision 1.8
diff -u -r1.8 Makefile.PL
--- Apache-Test/Makefile.PL 29 Apr 2003 06:37:47 - 1.8
+++ Apache-Test/Makefile.PL 20 May 2003 03:13:56 -
@@ -2,12 +2,14 @@
use ExtUtils::MakeMaker;
use Symbol;
+use File::Spec::Functions qw(catfile catdir);
use lib qw(lib);
my $VERSION;
use Apache::Test5005compat;
+use Apache::TestTrace;
use Apache::TestMM qw(test); #enable 'make test'
@@ -21,6 +23,8 @@
set_version();
+find_old_Apache_test_pm();
+
WriteMakefile(
NAME = 'Apache::Test',
VERSION = $VERSION,
@@ -57,5 +61,41 @@
EOF
return $string;
+}
+
+# on case-insensitive systems we want to alert users to remove
+# Apache/test.pm if any
+sub find_old_Apache_test_pm {
+my $is_case_insensitive = -e catfile qw(lib Apache testconfig.pm);
+
+return unless $is_case_insensitive;
+
+eval { require Apache::test };
+return if $@; # not found any m|Apache/[Tt]est.pm|
+
+my $old_file;
+
+unless (defined $Apache::Test::VERSION) {
+$old_file = $INC{Apache/test.pm};
+} else {
+# picked Apache/Test.pm instead of Apache/test.pm. Next
+# traverse manually to check whether we have
+# Apache/test.pm installed
+foreach (@INC) {
+my $dir = catdir $_, Apache;
+next unless -d $dir;
+opendir DIR, $dir or die Cannot opendir $dir: $!\n;
+my @matches = grep /^test.pm$/, readdir DIR;
+closedir DIR;
+next unless @matches;
+$old_file = catfile $dir, $matches[0];
+last;
+}
+}
+
+if ($old_file) {
+error Please remove the stale file $old_file, or you may .
+have problems running tests;
+}
}
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Folks please send your feedback on this last proposal, so we can close this issue asap. In case you have missed it: http://marc.theaimsgroup.com/?l=apache-test-devm=105288551432493w=2 __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Stas Bekman wrote: Folks please send your feedback on this last proposal, so we can close this issue asap. In case you have missed it: http://marc.theaimsgroup.com/?l=apache-test-devm=105288551432493w=2 the solution seems reasonable to me, but then again I never had a problem :) from what I remember, this wasn't really an issue on win32 either according to randy (due to the 5.6.1 and 5.8.0 issues or somesuch). so, I guess we just need david and some other OSX people to weigh in before moving forward. maybe committing the solution will help - I feel like we've kinda beat this to death. we can always back it out later if it doesn't work as intended, and having CVS up to date makes it easier for people to test everything. --Geoff
Re: resolving Apache::Test vs. Apache::test collision
On Fri, 16 May 2003, Geoffrey Young wrote: Stas Bekman wrote: Folks please send your feedback on this last proposal, so we can close this issue asap. In case you have missed it: http://marc.theaimsgroup.com/?l=apache-test-devm=105288551432493w=2 the solution seems reasonable to me, but then again I never had a problem :) from what I remember, this wasn't really an issue on win32 either according to randy (due to the 5.6.1 and 5.8.0 issues or somesuch). so, I guess we just need david and some other OSX people to weigh in before moving forward. maybe committing the solution will help - I feel like we've kinda beat this to death. we can always back it out later if it doesn't work as intended, and having CVS up to date makes it easier for people to test everything. I agree - the solution looks good. So if it's OK with the OSX people ... -- best regards, randy
Re: resolving Apache::Test vs. Apache::test collision
Stas Bekman wrote:
Geoffrey Young wrote:
I actually like Apache::TestPlan, it's most of the functionality that
this module provides. but there are a few subs that are not. May be
this other functionality should move elsewhere.
given that almost all of the functions from the various Test* packages
are exported by default and almost nobody specifies an import list
currently with Apache::Test, I wouldn't worry too much about shuffling
stuff around later after the immediate problem has been fixed.
This is what I see now as the simplest solution at all fronts:
1) keep the distro name Apache-Test.
2) s|Apache/Test.pm|Apache/TestPlan.pm|
3) contents of Apache/TestPlan.pm:
package Apache::Test;
$Apache::Test::VERSION = '1.02';
package Apache::TestPlan;
# what was previously Apache::Test code follows
I decided to nevertheless plug these two lines in:
package Apache::Test;
$Apache::Test::VERSION = '1.02';
so that CPAN will still index Apache::Test, and we can still tell
CPAN.pm to install Apache::Test, same for dependencies list. Also that's
where we maintain the distro's version.
Usage-wise, the only change you have to do is this:
perl -pi -e 's|use Apache::Test([\s;])|use Apache::TestPlan$1|' files
Is everybody happy with that solution?
Unfortunately this solution won't work. If you have
PREREQ_PM = {Apache::Test = 1.03},
MakeMaker is going to 'require Apache::Test' and either won't find it or will
find Apache::test on case-insensitive platforms.
What a bummer.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
David Wheeler wrote: On Thursday, May 8, 2003, at 05:44 PM, Stas Bekman wrote: 1) Integrate test.pm in Test.pm. I think we should bundle Apache::Test with future versions of mod_perl to make the maintenance simple and remove the original Apache::test from it. 2) Rename Apache::Test to Apache::Tester (or else) to resolve the collision. Rename the distro Apache-Test to Apache-TestHarness (or else) to avoid confusion. Looks like if we can provide a clean implementation of (1) that's would be the best solution. Randy says that it shouldn't be a problem with winFU. If David says that it's cool with MacOSX, let's try to take this route then. It's much more likely that someone would install 1.27 over an Apache::Test installation on Mac OS X than it is on Win32, apparently. But if you were to release 1.28 with the new integrated Apache::Test, it probably wouldn't be too much of a problem. You might want to post a quick query to macosx@perl.org to get a general feel from the Mac OS X Perl community. If an old mod_perl 1.0 is installed and it overrides Apache::Test, Makefile.PL will simply fail to satisfy the requirement of a specific version (because Apache::test's version is smaller than Apache::Test's). However taking again this track of overriding test.pm, we may still have a problem in the following situation: root installs mod_perl 1.27 system-wide, user installs Apache::Test locally (can't unlink Apache/test.pm), this can be a problem if user's @INC are added after the system-wide ones. But that would be silly, isn't it? If we are sticking with this track, we need to figure out the way to make sure that Apache/test.pm is nuked. David, if Apache-Test includes Apache/test.pm and Apache/Test.pm is it ensured that any other occurance of Apache/test.pm will be nuked? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Unfortunately this solution won't work. If you have
PREREQ_PM = {Apache::Test = 1.03},
MakeMaker is going to 'require Apache::Test' and either won't find it or
will find Apache::test on case-insensitive platforms.
What a bummer.
yes, I thought about that already as I began to revamp my distributions :)
the solution, of course, is to advocate prereq'ing Apache::TestPlan =
0 - it's a bit counterintuitive, but no different than downloading
libwww-perl and using a LWP::UserAgent prereq.
but really, this shouldn't be much of an issue - you generally prereq
module dependencies, not testing dependencies (yeah the tests will
fail, but there are steps you can take within the tests to keep that
from happening). and EU::MM only warns on missing prereqs anyway, so
it's never failsafe :)
for mp2 users you'll be able to prereq mod_perl 1.9910 and that should
cover almost all cases (save a few weeks of CVS). for mp1 users
eval'ing 'require Apache::TestPlan' will be sufficient, since you
require() the modules anyway to avoid failing makefiles. for the
others, well, altering the tests to require one or the other or
requiring TestPlan will be the only way.
so the main version lives in TestPlan instead of a file matching the
dist name - that happens with other modules so it's not all that
strange or difficult to live with.
--Geoff
Re: resolving Apache::Test vs. Apache::test collision
Geoffrey Young wrote:
Unfortunately this solution won't work. If you have
PREREQ_PM = {Apache::Test = 1.03},
MakeMaker is going to 'require Apache::Test' and either won't find it
or will find Apache::test on case-insensitive platforms.
What a bummer.
yes, I thought about that already as I began to revamp my distributions :)
the solution, of course, is to advocate prereq'ing Apache::TestPlan = 0
- it's a bit counterintuitive, but no different than downloading
libwww-perl and using a LWP::UserAgent prereq.
but really, this shouldn't be much of an issue - you generally prereq
module dependencies, not testing dependencies (yeah the tests will fail,
but there are steps you can take within the tests to keep that from
happening). and EU::MM only warns on missing prereqs anyway, so it's
never failsafe :)
for mp2 users you'll be able to prereq mod_perl 1.9910 and that should
cover almost all cases (save a few weeks of CVS). for mp1 users
eval'ing 'require Apache::TestPlan' will be sufficient, since you
require() the modules anyway to avoid failing makefiles. for the
others, well, altering the tests to require one or the other or
requiring TestPlan will be the only way.
so the main version lives in TestPlan instead of a file matching the
dist name - that happens with other modules so it's not all that strange
or difficult to live with.
eh, no, the prereq is LWP, not LWP::UserAgent, look at LWP.pm:
package LWP;
$VERSION = 5.69;
sub Version { $VERSION; }
require 5.004;
require LWP::UserAgent; # this should load everything you need
1;
so libwww-perl = LWP is intuitive
Apache-Test = Apache::TestPlan is not
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
David Wheeler wrote: On Thursday, May 8, 2003, at 05:44 PM, Stas Bekman wrote: 1) Integrate test.pm in Test.pm. I think we should bundle Apache::Test with future versions of mod_perl to make the maintenance simple and remove the original Apache::test from it. 2) Rename Apache::Test to Apache::Tester (or else) to resolve the collision. Rename the distro Apache-Test to Apache-TestHarness (or else) to avoid confusion. Looks like if we can provide a clean implementation of (1) that's would be the best solution. Randy says that it shouldn't be a problem with winFU. If David says that it's cool with MacOSX, let's try to take this route then. It's much more likely that someone would install 1.27 over an Apache::Test installation on Mac OS X than it is on Win32, apparently. But if you were to release 1.28 with the new integrated Apache::Test, it probably wouldn't be too much of a problem. You might want to post a quick query to macosx@perl.org to get a general feel from the Mac OS X Perl community. I think it's simpler to eliminate Apache/Test.pm. It introduces very little trouble to the current users of Apache::Test, which aren't many who put their things on CPAN. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
I actually like Apache::TestPlan, it's most of the functionality that this module provides. but there are a few subs that are not. May be this other functionality should move elsewhere. given that almost all of the functions from the various Test* packages are exported by default and almost nobody specifies an import list currently with Apache::Test, I wouldn't worry too much about shuffling stuff around later after the immediate problem has been fixed. I dunno, I'm terrible with names anyway, so I'll shut up now and just wait for the results :) No, no, you can't just wait for the results. you're right :) /me waits patiently for the next release... --Geoff
Re: resolving Apache::Test vs. Apache::test collision
Geoffrey Young wrote: 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. not to be nitpicky, but Apache::Tester strikes me as, well, something. this is a really cool piece of software that has the potential to make many, many developer's lives easier - having a descriptive, decent name is probably important. (though getting everyone to agree may be difficult ;) how about Apache::TestHarness or Apache::TestSuite or something similar? We already have the Apache::TestHarness module. But I see no problem moving the $VERSION control into that module and release it as Apache-TestHarness, and rename the Apache::Test module to a different name. speaking of which, despite CPAN's general dislike of multi-level naming schemes, would Apache::Test::Harness make life easier? technically, we could keep everything other than Test.pm as is, avoid namespace collisions, and still refer to the whole thing (colloquially) as Apache::Test. ok, well it's just an idea... That won't work well, because if the distro is named Apache-Test, people will try to install Apache::Test via CPAN. or search for it in search.cpan.org. Also I don't get what good the multi-level naming will do to the resolving this problem. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Randy Kobes wrote: On Thu, 8 May 2003, Stas Bekman wrote: 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. That's certainly true in general (for case-preserving but otherwise case-insensitive file systems) - I just thought I'd clarify why this problem never really arose before on ActivePerl Win32. There, mod_perl 1 works with perl-5.6.1 but not with perl-5.8.0 (due to large files support), and mod_perl 2 works with perl-5.8.0, but not (practically speaking) with perl-5.6.1. So it's very rare that Apache::test and Apache::Test would get installed within the same Perl tree, at least while these two were tied to particular mod_perl versions. Cool. What about MacOSX? Any other systems? The other issue is that we have to ship and install Test.pm and test.pm, because mp1 users will need test.pm on case-sensitive systems. On case insensitive systems only one of these will be installed (the other will overwrite the first one). __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Randy Kobes wrote: On Thu, 8 May 2003, Stas Bekman wrote: [ .. ] 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 CPAN.pm, and that won't work. Probably to make a clean break the whole package should be renamed. And also, probably the current Apache-Test packages on CPAN should be deleted, as Apache::Test would still show up in the CPAN indices, under older Apache-Test packages (eg, there's some obsolete modules in older versions of libwww-perl that can be seen within CPAN.pm). I think though that the Apache::Test module would still remain in the indices after such deletion, and CPAN.pm would direct queries to the module owner. You'll probably have to contact modules@perl.org to get the module itself removed from the indices. Yes, that shouldn't be a problem. So currently we are down to two options: 1) Integrate test.pm in Test.pm. I think we should bundle Apache::Test with future versions of mod_perl to make the maintenance simple and remove the original Apache::test from it. 2) Rename Apache::Test to Apache::Tester (or else) to resolve the collision. Rename the distro Apache-Test to Apache-TestHarness (or else) to avoid confusion. Looks like if we can provide a clean implementation of (1) that's would be the best solution. Randy says that it shouldn't be a problem with winFU. If David says that it's cool with MacOSX, let's try to take this route then. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
So currently we are down to two options: 1) Integrate test.pm in Test.pm. I think we should bundle Apache::Test with future versions of mod_perl to make the maintenance simple and remove the original Apache::test from it. if you mean future versions of mp1, that's a good idea. that's probably reason enough to release 1.28 when we get this all sorted out. 2) Rename Apache::Test to Apache::Tester (or else) to resolve the collision. Rename the distro Apache-Test to Apache-TestHarness (or else) to avoid confusion. actually, I hadn't thought about it much, so I didn't realize that we could keep Apache-Test as the distribution name while changing the offending file (*duh*). sticking with Apache-Test as the distribution gets my vote. I don't think it's too confusing - other major distributions use packages that differ from the distribution name (libwww-perl, perl-ldap, Filter, etc). now I care much less about the name of the package that actually supplies the base functions - Apache::Tester is fine with me. Apache::TestPlan also sorta makes sense, since then use Apache::TestPlan; use Apache::TestRequest; mirror what's really happening - one package is required for planning (and other housekeeping functions) and one is required for issuing the requests. I dunno, I'm terrible with names anyway, so I'll shut up now and just wait for the results :) --Geoff
Re: resolving Apache::Test vs. Apache::test collision
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/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. 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 CPAN.pm, and that won't work. Notice that we can't put in a dummy Apache/Test.pm, because it'll overwrite Apache/test.pm and break mp1 test suites. But may be if we copy Apache/test.pm to Apache/Test.pm 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 Apache/Tester.pm __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Stas Bekman wrote: We have a problem with using the Apache::Test name, more correctly we have a problem with using the Apache/Test.pm filename. On platforms with case-insentive filesystems (winFU, Mac OS X) if mod_perl 1.x is installed, there is Apache/test.pm (notice the lower case 't'). So when you say 'use Apache::Test' it loads Apache::test. Boom, nothing works. ok, so it's not like that I don't believe that this is an issue, but I don't believe you - if you have Apache/test.pm and you install 2.0 then Apache/Test.pm would replace the existing file, no? that's why Apache2 is around for all the mod_perl based stuff - to keep Apache::Filter from 2.0 from cloberring Apache::Filter from 1.0 if installing Apache::Test doesn't clobber Apache::test on case-insensitive installations, _that_ seems like a bug to me :) There are several routes we can take to resolve this problem: 1. rename Apache::Test to something else. David Wheeler has proposed to use Apache::Tester (or even swap the sides: Test::Apache). that seems ok (if you buy into the argument, anyway) 2. add a new package Apache::TestLoad which will deal with loading the right Apache::Test package, by replacing 'require Apache::Test' with search for 'Apache/Test.pm' in @INC and doing do $file; on the full path. That solves the problem, of loading the right file but you will have to replace all instances of 'use Apache::Test;' with 'use Apache::TestLoad;', but still using the functions from Apache::Test. Since they are all imported by default, this is not a big issue. It's just confusing that use 'Apache::TestLoad'. yucko - use()ing Apache::TestLoad methods just doesn't seem right. I can see a third possibility - installing Apache::Test relative to Apache2, that way there is no namespace collision and uses can control their destiny. --Geoff
Re: resolving Apache::Test vs. Apache::test collision
I can see a third possibility - installing Apache::Test relative to Apache2, that way there is no namespace collision and uses can control their destiny. This is not an option. Apache::Test should be available unrelated to availability of mp2. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
David Wheeler wrote: On Monday, May 5, 2003, at 05:19 PM, Geoffrey Young wrote: ok, so it's not like that I don't believe that this is an issue, but I don't believe you - if you have Apache/test.pm and you install 2.0 then Apache/Test.pm would replace the existing file, no? that's why Apache2 is around for all the mod_perl based stuff - to keep Apache::Filter from 2.0 from cloberring Apache::Filter from 1.0 The problem is not when you install mod_perl2 (though it might be, I honestly have no idea). The problem is when you have mod_perl1 and install Apache::Test from CPAN. No mp2 involved. it could be the same issue when installing mp2, but as you say it's unrelated. if installing Apache::Test doesn't clobber Apache::test on case-insensitive installations, _that_ seems like a bug to me :) Agreed. See http://rt.perl.org/rt2/Ticket/Display.html?id=22077 bug or not bug, we have to deal with older perls. My other suggestion was: I think I have another idea. Remember I was proposing to replace Apache/test.pm with a new Apache/test.pm with the same functionality. The problem you said was that Apache/test.pm from mp1 was installed in a different location. But if we provide both Apache/test.pm and Apache/Test.pm (which would be really the same file, so whichever [Tt]est.pm will be picked it'll just work), won't Makefile.PL deal with that correctly? It will warn a user if there is another Apache/test.pm installed elsewhere and UNINST=1 will nuke it. And David has replied: Hrm, dunno. Given a case-insensitive file system, I would think that such a check in Makefile.PL would work correctly, anyway, finding Apache::test when installing Apache::Test. OTOH, I recently upgraded Locale::Maketext from CPAN, and it didn't overwrite the version distributed as part of the core, even though they _are_ named exactly the same way. So it's actually a good thing that you have raised this issue. If it was overriding Apache/test.pm people won't be able to run tests on their mp1 Apache:: modules. So it seems that the only correct solution (assuming that we don't want to rename Apache::Test), is to provide a back-compatibility functionality inside Apache::Test and install Apache/Test.pm and Apache/test.pm (which should be the same thing, so no matter what OS decides to load it still works the same. And Apache::Test's Makefile.PL has to find any installed Apache/test.pm and nuke it on 'make install', replacing with an imposter version of Apache/test.pm. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
David Wheeler wrote: On Monday, May 5, 2003, at 06:13 PM, Joe Schaefer wrote: Seems like a workable compromise to me: if all we have to do is s/Apache::Test/Test::Apache/ for libapreq-1.x, that seems easy enough. You know, we might be able to eliminate this whole problem by having Apache::Test be compatible with Apache::test, and just using INSTALLVENDORARCH in Makefile.PL to replace Apache/test.pm, which on my system is in /usr/local/lib/perl5/site_perl/5.8.0/darwin/Apache/test.pm. I don't think this will be robust enough, since vendors tend to do things in their own subtle ways. It's probably much better to explicitly search @INC, rather than relying on INSTALLVENDORARCH. p.s. the Apache/test.pm is quite big but should be ok if it's never be modified, which I hope is the case... __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
David Wheeler wrote: On Monday, May 5, 2003, at 07:34 PM, Stas Bekman wrote: I don't think this will be robust enough, since vendors tend to do things in their own subtle ways. It's probably much better to explicitly search @INC, rather than relying on INSTALLVENDORARCH. Hrm, yes, I guess you're right. I was thinking that that would put it wherever mp1's make install put it, but vendors may have done all sorts of kookie things with it. ;) p.s. the Apache/test.pm is quite big but should be ok if it's never be modified, which I hope is the case... Isn't Ken Williams the maintainer? Of Apache::test? Nope, it's in the modperl-1.xx package. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
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
