Re: cvs commit: httpd-test/perl-framework/Apache-Test Changes
Sander Temme wrote:
on 5/20/03 10:53, Sander Temme at [EMAIL PROTECTED] wrote:
This breaks on RH 8.0 and Solaris 7, both on perl 5.8.0, with the following
The following patch gets me back in the saddle, not only on Linux/Solaris
but also on Darwin 6.6:
Index: Apache-Test/lib/Apache/TestConfig.pm
===
RCS file:
/home/cvspublic/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.
pm,v
retrieving revision 1.162
diff -u -r1.162 TestConfig.pm
--- Apache-Test/lib/Apache/TestConfig.pm20 May 2003 06:01:38 -
1.162
+++ Apache-Test/lib/Apache/TestConfig.pm20 May 2003 18:18:08 -
@@ -781,7 +781,7 @@
push @dirs, '../lib';
}
-push @dirs, 'Apache-Test' if IS_MOD_PERL_2_BUILD;
+push @dirs, 'Apache-Test/lib';
return <<"EOF";
I'm not building mod_perl, so that Apache-Test did not get included on
Darwin (running perl 5.6.0 which apparently doesn't choke on the constant)
and furthermore it needs to be Apache-Test/lib.
Please let me know if I'm onto something, or merely on something.
Yes, yes, I've messed things up a bit. My goal was to cleanup @INC from
non-existing dirs. Therefore can you try this patch:
Index: Apache-Test/lib/Apache/TestConfig.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v
retrieving revision 1.162
diff -u -r1.162 TestConfig.pm
--- Apache-Test/lib/Apache/TestConfig.pm20 May 2003 06:01:38 -
1.162
+++ Apache-Test/lib/Apache/TestConfig.pm20 May 2003 23:33:27 -
@@ -781,7 +781,13 @@
push @dirs, '../lib';
}
-push @dirs, 'Apache-Test' if IS_MOD_PERL_2_BUILD;
+for (qw(. ..)) {
+my $dir = catdir $FindBin::Bin, "..", $_ , "Apache-Test", "lib";
+if (-d $dir) {
+push @dirs, $dir;
+last;
+}
+}
return <<"EOF";
__
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: Apache::Test renaming foo
Geoffrey Young wrote: that other thread was becoming too much to follow :) Or would you rather say, that you are anxious to publish the article? ;) I thought it might be a nice idea to wrap up the issues thus far because it seems to me we have a consensus on how to resolve the Apache::[Tt]est collision issues. from what I can see, stas has come up with a few patches that make it possible for Apache-Test to be distributed such that current Apache::Test users will not need to make any interface changes. Apache::test users will need to install/upgrade to Apache-Test 1.03 in order to be certain that their tests will find the proper Apache::test module on all platforms (namely OS X). of course, this all assumes that the tests themselves are platform independent, in which case they would be failing anyway :) in short, the current and documented API is remaining as is (barring any yet unseen issues :) and only users of the current Apache::test are affected. does that about sum it up? The latest development on this front is different. The idea is to leave Apache-Test as is, and rename Apache::test to Apache::testold or similar. Adjust mod_perl-1.28 to use Apache::testold and migrate all 3rd party modules to use Apache::testold by requiring mod_perl-1.28, or bundle the old Apache/test in their distros, untill they get a chance to port to Apache::Test. I'm not sure if we should distribute Apache::testold in Apache-Test. I'd rather see this module as becoming deprecated. Geoff, it'd be nice for your article to sum up this issue, once everybody is happy with it. Looks to me like a perfect place and time. __ 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
Apache::Test renaming foo
that other thread was becoming too much to follow :) I thought it might be a nice idea to wrap up the issues thus far because it seems to me we have a consensus on how to resolve the Apache::[Tt]est collision issues. from what I can see, stas has come up with a few patches that make it possible for Apache-Test to be distributed such that current Apache::Test users will not need to make any interface changes. Apache::test users will need to install/upgrade to Apache-Test 1.03 in order to be certain that their tests will find the proper Apache::test module on all platforms (namely OS X). of course, this all assumes that the tests themselves are platform independent, in which case they would be failing anyway :) in short, the current and documented API is remaining as is (barring any yet unseen issues :) and only users of the current Apache::test are affected. does that about sum it up? --Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test Changes
on 5/20/03 10:53, Sander Temme at [EMAIL PROTECTED] wrote: > This breaks on RH 8.0 and Solaris 7, both on perl 5.8.0, with the following The following patch gets me back in the saddle, not only on Linux/Solaris but also on Darwin 6.6: Index: Apache-Test/lib/Apache/TestConfig.pm === RCS file: /home/cvspublic/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig. pm,v retrieving revision 1.162 diff -u -r1.162 TestConfig.pm --- Apache-Test/lib/Apache/TestConfig.pm20 May 2003 06:01:38 - 1.162 +++ Apache-Test/lib/Apache/TestConfig.pm20 May 2003 18:18:08 - @@ -781,7 +781,7 @@ push @dirs, '../lib'; } -push @dirs, 'Apache-Test' if IS_MOD_PERL_2_BUILD; +push @dirs, 'Apache-Test/lib'; return <<"EOF"; I'm not building mod_perl, so that Apache-Test did not get included on Darwin (running perl 5.6.0 which apparently doesn't choke on the constant) and furthermore it needs to be Apache-Test/lib. Please let me know if I'm onto something, or merely on something. Thanks, S. -- Covalent Technologies [EMAIL PROTECTED] Engineering groupVoice: (415) 856 4214 303 Second Street #375 South Fax: (415) 856 4210 San Francisco CA 94107 PGP Fingerprint: 7A8D B189 E871 80CB 9521 9320 C11E 7B47 964F 31D9 === This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message ===
Re: cvs commit: httpd-test/perl-framework/Apache-Test Changes
on 5/19/03 23:01, [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: This breaks on RH 8.0 and Solaris 7, both on perl 5.8.0, with the following protest: pxs /tmp/apache2/bin/apxs Useless use of a constant in void context at Apache-Test/lib/Apache/TestConfig.pm line 784. Compilation failed in require at Apache-Test/lib/Apache/TestMM.pm line 7. BEGIN failed--compilation aborted at Apache-Test/lib/Apache/TestMM.pm line 7. Compilation failed in require at Makefile.PL line 9. BEGIN failed--compilation aborted at Makefile.PL line 9. The offending line is the following: > +push @dirs, 'Apache-Test' if IS_MOD_PERL_2_BUILD; Does that IS_MOD_PERL_2_BUILD need to be in a name space when it is referenced within the subroutine? S. -- Covalent Technologies [EMAIL PROTECTED] Engineering groupVoice: (415) 856 4214 303 Second Street #375 South Fax: (415) 856 4210 San Francisco CA 94107 PGP Fingerprint: 7A8D B189 E871 80CB 9521 9320 C11E 7B47 964F 31D9 === This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message ===
Re: resolving Apache::Test vs. Apache::test collision
I think there are quite a lot of them: http://search.cpan.org/search?query=Apache::test&mode=all that list is actually a bit decieving - I took a look at the Apache:: modules that show up and, of the few I chose at random, none used Apache::test. the only ones I know of are Ken Williams modules, namely Apache::SSI, Apache::Compress, and Apache::Filter, though there may be a few others. --Geoff
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
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
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
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::test&mode=all But IIRC, most have Apache::test in their distros, and since use C 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
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 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 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
