You are viewing a plain text version of this content. The canonical link for it is here.
Posted to test-dev@httpd.apache.org by Stas Bekman <st...@stason.org> on 2003/05/06 02:01:00 UTC
resolving Apache::Test vs. Apache::test collision
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).
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'.
So the first solution is probably the cleanest in the long run, there will be
some mess while moving things to a new name, but since I don't think many
developers are using this package yet, it won't be as bad as it could be at a
later stage.
The second solution allows to keep things as they are on CPAN, cvs rep, etc,
but s/use Apache::Test;/use Apache::TestLoad;/
To me the first solution is favorite for the users of the module, the second
one for its maintainers.
Now please help to make the right choice, and if of course you have other
ideas, let us know.
And the patch for the second solution:
find t -type f -exec perl -pi -e 's/use Apache::Test;/use Apache::TestLoad;/'
{} \;
Index: lib/Apache/TestMM.pm
===================================================================
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestMM.pm,v
retrieving revision 1.25
diff -u -r1.25 TestMM.pm
--- lib/Apache/TestMM.pm 1 May 2003 06:22:35 -0000 1.25
+++ lib/Apache/TestMM.pm 5 May 2003 00:01:44 -0000
@@ -4,6 +4,7 @@
use warnings FATAL => 'all';
use Config;
+use Apache::TestLoad ();
use Apache::TestConfig ();
use Apache::TestTrace;
--- /dev/null 1970-01-01 10:00:00.000000000 +1000
+++ lib/Apache/TestLoad.pm 2003-05-05 09:50:29.000000000 +1000
@@ -0,0 +1,57 @@
+package Apache::TestLoad;
+
+use strict;
+use warnings FATAL => 'all';
+
+use File::Spec::Functions qw(catfile catdir);
+
+require Apache::Test;
+
+unless (defined $Apache::Test::VERSION) {
+ 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;
+ my $file = catfile $dir, $matches[0];
+ do $file;
+ last;
+ }
+}
+
+die "Still can't find Apache::Test"
+ unless defined defined $Apache::Test::VERSION;
+
+sub import {
+ my $package = shift;
+ unshift @_, 'Apache::Test';
+ goto &{Apache::Test->can('import')};
+}
+
+1;
+
+__END__
+
+=pod
+
+=head1 NAME
+
+Apache::TestLoad - Load the correct Apache::Test
+
+=head1 SYNOPSIS
+
+ use Apache::TestLoad;
+
+=head1 DESCRIPTION
+
+If you want to use C<Apache::Test>, you should load
+C<Apache::TestLoad> instead. This is a workaround because some case
+insensitive filesystems may load I<Apache/test.pm> instead of
+I<Apache/Test.pm> where mod_perl 1.0 is installed.
+
+Luckily we can manually walk the @INC dirs and force to load
+I<Apache/Test.pm>.
+
+=cut
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
> 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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
> 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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
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
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
> 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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> 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:
[...]
> worked for me on Win32 in uninstalling an existing test.pm in all
> possible @INC locations before installing the new Test.pm.
Thank you, Randy. I've committed your fixed version. It works for me as well.
Now just awaiting a confirmation from David and I'll put Apache::Test 1.03 on
CPAN.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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 -0000 1.8
+++ Makefile.PL 18 Jun 2003 02:38:58 -0000
@@ -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:
+
+@{[join "\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
Posted by Stas Bekman <st...@stason.org>.
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 -0000 1.8
+++ Makefile.PL 17 Jun 2003 02:51:17 -0000
@@ -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:
+
+@{[join "\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
Posted by Stas Bekman <st...@stason.org>.
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'.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
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
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
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
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 -0000 1.26
+++ Changes 16 Jun 2003 06:40:03 -0000
@@ -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 -0000 1.8
+++ Makefile.PL 16 Jun 2003 06:40:03 -0000
@@ -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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 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?
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...
--Geoff
Re: resolving Apache::Test vs. Apache::test collision
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 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?
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...
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>
> 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
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 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
>
> Is everybody happy with that solution?
yup, sounds good to me.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by "Philippe M. Chiasson" <go...@cpan.org>.
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 = '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?
[late on this thread, but nontheless] I also like it
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
>
--
-- -----------------------------------------------------------------------------
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
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 ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Tue, 13 May 2003, Stas Bekman wrote:
>
> [ .. ]
>
>>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.
>
>
> I'm not familiar enough with how PAUSE indexes modules contained
> in a distribution ... Does it search all .pm files for package
> declarations and index what it finds? For example, CPAN.pm itself
> contains several packages in the same file, but these don't show
> up in the indices (but that might be because these modules
> haven't been registered in PAUSE).
It scans all files. And yes you are talking about registered ones.
>>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?
>
>
> That sounds good ... So with this Apache::test of mod_perl 1
> wouldn't be affected at all?
As long as we have no physical Apache/Test.pm, no. Also the option of using an
dual-life Apache::{test|Test} doesn't go away.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Tue, 13 May 2003, Stas Bekman wrote:
>
> [ .. ]
>
>>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.
>
>
> I'm not familiar enough with how PAUSE indexes modules contained
> in a distribution ... Does it search all .pm files for package
> declarations and index what it finds? For example, CPAN.pm itself
> contains several packages in the same file, but these don't show
> up in the indices (but that might be because these modules
> haven't been registered in PAUSE).
It scans all files. And yes you are talking about registered ones.
>>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?
>
>
> That sounds good ... So with this Apache::test of mod_perl 1
> wouldn't be affected at all?
As long as we have no physical Apache/Test.pm, no. Also the option of using an
dual-life Apache::{test|Test} doesn't go away.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 13 May 2003, Stas Bekman wrote:
[ .. ]
> 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.
I'm not familiar enough with how PAUSE indexes modules contained
in a distribution ... Does it search all .pm files for package
declarations and index what it finds? For example, CPAN.pm itself
contains several packages in the same file, but these don't show
up in the indices (but that might be because these modules
haven't been registered in PAUSE).
> 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?
That sounds good ... So with this Apache::test of mod_perl 1
wouldn't be affected at all?
--
best regards,
randy
Re: resolving Apache::Test vs. Apache::test collision
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 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
>
> Is everybody happy with that solution?
yup, sounds good to me.
--Geoff
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 13 May 2003, Stas Bekman wrote:
[ .. ]
> 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.
I'm not familiar enough with how PAUSE indexes modules contained
in a distribution ... Does it search all .pm files for package
declarations and index what it finds? For example, CPAN.pm itself
contains several packages in the same file, but these don't show
up in the indices (but that might be because these modules
haven't been registered in PAUSE).
> 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?
That sounds good ... So with this Apache::test of mod_perl 1
wouldn't be affected at all?
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by "Philippe M. Chiasson" <go...@cpan.org>.
[ This message is resent on behalf of Philippe M. Chiasson
<go...@cpan.org>. -- 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 Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
>
--
-- ------------------------------------------------------------------------=
-----
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--
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 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
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>
>> 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.
For that to happen, someone has to spend time with it. I know that I get at
least several tests failing with the current cvs. Also there are quite a few
patches that weren't applied I think. That's why a few months ago I was
looking for someone to bring this version to a production quality.
>> 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).
Hey, I haven't thought about this possibility ;)
> 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 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.
> 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.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>
>> 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.
For that to happen, someone has to spend time with it. I know that I get at
least several tests failing with the current cvs. Also there are quite a few
patches that weren't applied I think. That's why a few months ago I was
looking for someone to bring this version to a production quality.
>> 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).
Hey, I haven't thought about this possibility ;)
> 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 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.
> 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.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>
> 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
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Fri, 9 May 2003, Stas Bekman wrote:
>
> [ .. ]
>
>>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.
>
>
> I'd tend to agree with (1) ... Would that mean that mod_perl 1
> (and any 3rd party mod_perl 1 packages that use it) would have to
> change a 'use Apache::test' to 'use Apache::Test'?
We don't want that to happen.
> Or would
> Apache/test.pm become an identical copy of Apache/Test.pm, with
> both being installed?
I was thinking to distribute both files as identical copies (both including
packages Apache::Test and Apache::test). And on the case-insensitive systems,
only one will get actually installed.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Fri, 9 May 2003, Stas Bekman wrote:
>
> [ .. ]
>
>>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.
>
>
> I'd tend to agree with (1) ... Would that mean that mod_perl 1
> (and any 3rd party mod_perl 1 packages that use it) would have to
> change a 'use Apache::test' to 'use Apache::Test'?
We don't want that to happen.
> Or would
> Apache/test.pm become an identical copy of Apache/Test.pm, with
> both being installed?
I was thinking to distribute both files as identical copies (both including
packages Apache::Test and Apache::test). And on the case-insensitive systems,
only one will get actually installed.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 9 May 2003, Stas Bekman wrote:
[ .. ]
> 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.
I'd tend to agree with (1) ... Would that mean that mod_perl 1
(and any 3rd party mod_perl 1 packages that use it) would have to
change a 'use Apache::test' to 'use Apache::Test'? Or would
Apache/test.pm become an identical copy of Apache/Test.pm, with
both being installed?
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 9 May 2003, Stas Bekman wrote:
[ .. ]
> 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.
I'd tend to agree with (1) ... Would that mean that mod_perl 1
(and any 3rd party mod_perl 1 packages that use it) would have to
change a 'use Apache::test' to 'use Apache::Test'? Or would
Apache/test.pm become an identical copy of Apache/Test.pm, with
both being installed?
--
best regards,
randy
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
On Friday, May 16, 2003, at 07:37 AM, Randy Kobes wrote:
> I agree - the solution looks good. So if it's OK with the OSX
> people ...
Sorry, on a client site and haven't had time to test. Hopefully will
have time in the next few days.
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
[ This message is resent on behalf of David Wheeler <da...@wheeler.net>.
-- justin ]
On Friday, May 16, 2003, at 07:37 AM, Randy Kobes wrote:
> I agree - the solution looks good. So if it's OK with the OSX
> people ...
Sorry, on a client site and haven't had time to test. Hopefully will
have time in the next few days.
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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-dev&m=105288551432493&w=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
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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-dev&m=105288551432493&w=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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
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-dev&m=105288551432493&w=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
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
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-dev&m=105288551432493&w=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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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-dev&m=105288551432493&w=2
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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-dev&m=105288551432493&w=2
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
On Thursday, May 22, 2003, at 06:32 AM, Randy Kobes wrote:
> 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
KWILLIAMS, DROLSKY, and DWHEELER, at least, all include
t/lib/Apache/test.pm in their distributions. I've already mentioned to
Ken that Apache::Test is worth switching to. I'll try to locate some
tuits to upgrade the tests in my module, too.
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Fri, 23 May 2003, Stas Bekman wrote:
>
>
>>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?
>
>
> By a strange coincidence, the system I have extracts those .pm
> files that have pod content, so this was simple to find - the
> packages that include an Apache::test are
>
> Apache-AppCluster/Server/t/Apache/test.pm
> Apache-AuthCookie/t/Apache/test.pm
> Apache-Compress/t/Apache/test.pm
> Apache-Filter/t/Apache/test.pm
> Apache-SSI/t/Apache/test.pm
> AxKit-Needs/mod_perl/mod_perl-1.26/Apache/test.pm
> HTML-Mason/t/Apache/test.pm
> mod_perl/Apache/test.pm
> MasonX-ApacheHandler-WithCallbacks/t/Apache/test.pm
>
> This was done on Linux, so Apache/test.pm really is
> Apache::test, and not Apache::Test :)
So these bundle the file and therefore out of trouble. Can you please grep for
Apache::test to see what others are using it but not bundling it? And get the
narrowed down list of cpan_id/modules?
Thanks a lot, Randy.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Fri, 23 May 2003, Stas Bekman wrote:
>
>
>>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?
>
>
> By a strange coincidence, the system I have extracts those .pm
> files that have pod content, so this was simple to find - the
> packages that include an Apache::test are
>
> Apache-AppCluster/Server/t/Apache/test.pm
> Apache-AuthCookie/t/Apache/test.pm
> Apache-Compress/t/Apache/test.pm
> Apache-Filter/t/Apache/test.pm
> Apache-SSI/t/Apache/test.pm
> AxKit-Needs/mod_perl/mod_perl-1.26/Apache/test.pm
> HTML-Mason/t/Apache/test.pm
> mod_perl/Apache/test.pm
> MasonX-ApacheHandler-WithCallbacks/t/Apache/test.pm
>
> This was done on Linux, so Apache/test.pm really is
> Apache::test, and not Apache::Test :)
So these bundle the file and therefore out of trouble. Can you please grep for
Apache::test to see what others are using it but not bundling it? And get the
narrowed down list of cpan_id/modules?
Thanks a lot, Randy.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 23 May 2003, Stas Bekman wrote:
>
> 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?
By a strange coincidence, the system I have extracts those .pm
files that have pod content, so this was simple to find - the
packages that include an Apache::test are
Apache-AppCluster/Server/t/Apache/test.pm
Apache-AuthCookie/t/Apache/test.pm
Apache-Compress/t/Apache/test.pm
Apache-Filter/t/Apache/test.pm
Apache-SSI/t/Apache/test.pm
AxKit-Needs/mod_perl/mod_perl-1.26/Apache/test.pm
HTML-Mason/t/Apache/test.pm
mod_perl/Apache/test.pm
MasonX-ApacheHandler-WithCallbacks/t/Apache/test.pm
This was done on Linux, so Apache/test.pm really is
Apache::test, and not Apache::Test :)
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 23 May 2003, Stas Bekman wrote:
>
> 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?
By a strange coincidence, the system I have extracts those .pm
files that have pod content, so this was simple to find - the
packages that include an Apache::test are
Apache-AppCluster/Server/t/Apache/test.pm
Apache-AuthCookie/t/Apache/test.pm
Apache-Compress/t/Apache/test.pm
Apache-Filter/t/Apache/test.pm
Apache-SSI/t/Apache/test.pm
AxKit-Needs/mod_perl/mod_perl-1.26/Apache/test.pm
HTML-Mason/t/Apache/test.pm
mod_perl/Apache/test.pm
MasonX-ApacheHandler-WithCallbacks/t/Apache/test.pm
This was done on Linux, so Apache/test.pm really is
Apache::test, and not Apache::Test :)
--
best regards,
randy
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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 cpanid@cpan.org.
=======================================================
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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 cpanid@cpan.org.
=======================================================
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
Posted by Stas Bekman <st...@stason.org>.
David Wheeler wrote:
> On Wednesday, May 21, 2003, at 08:10 PM, Stas Bekman wrote:
>
>> Good point. We will do that from Apache-Test which I plan to bundle
>> with 1.28 as well to make it spread faster to users and encourage
>> developers to use it.
>
>
> Cool, and good thinking.
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?
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.
With regards to releasing mod_perl 1.28 somebody has to wear the release
manager cap: address any burning issues in the STATUS file and bring it to a
release quality. Any volunteers?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
David Wheeler wrote:
> On Wednesday, May 21, 2003, at 08:10 PM, Stas Bekman wrote:
>
>> Good point. We will do that from Apache-Test which I plan to bundle
>> with 1.28 as well to make it spread faster to users and encourage
>> developers to use it.
>
>
> Cool, and good thinking.
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?
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.
With regards to releasing mod_perl 1.28 somebody has to wear the release
manager cap: address any burning issues in the STATUS file and bring it to a
release quality. Any volunteers?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
-- justin ]
On Wednesday, May 21, 2003, at 08:10 PM, Stas Bekman wrote:
> Good point. We will do that from Apache-Test which I plan to bundle
> with 1.28 as well to make it spread faster to users and encourage
> developers to use it.
Cool, and good thinking.
Good luck with it!
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
On Wednesday, May 21, 2003, at 08:10 PM, Stas Bekman wrote:
> Good point. We will do that from Apache-Test which I plan to bundle
> with 1.28 as well to make it spread faster to users and encourage
> developers to use it.
Cool, and good thinking.
Good luck with it!
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
David Wheeler wrote:
> On Wednesday, May 21, 2003, at 07:37 PM, Stas Bekman wrote:
>
>> David, the latest wind is not to do anything at all with Apache-Test.
>>
>> Instead replace Apache/test.pm with Apache/testold.pm in the mod_perl
>> distro and ask all those who use Apache::test (which should be very
>> few) to re-release their packages using Apache::testold (and even
>> better Apache::Test) or simply bundle Apache/test.pm in their t/ or
>> inc/ subdirs (so it wouldn't get installed).
>
>
> That's fine with me. You'll still have to have mod_perl 1.28 uninstall
> the old test.pm, though. If you just change it to testold.pm in the
> mod_perl distro, test.pm will be left alone unless it is uninstalled.
Good point. We will do that from Apache-Test which I plan to bundle with 1.28
as well to make it spread faster to users and encourage developers to use it.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
David Wheeler wrote:
> On Wednesday, May 21, 2003, at 07:37 PM, Stas Bekman wrote:
>
>> David, the latest wind is not to do anything at all with Apache-Test.
>>
>> Instead replace Apache/test.pm with Apache/testold.pm in the mod_perl
>> distro and ask all those who use Apache::test (which should be very
>> few) to re-release their packages using Apache::testold (and even
>> better Apache::Test) or simply bundle Apache/test.pm in their t/ or
>> inc/ subdirs (so it wouldn't get installed).
>
>
> That's fine with me. You'll still have to have mod_perl 1.28 uninstall
> the old test.pm, though. If you just change it to testold.pm in the
> mod_perl distro, test.pm will be left alone unless it is uninstalled.
Good point. We will do that from Apache-Test which I plan to bundle with 1.28
as well to make it spread faster to users and encourage developers to use it.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
-- justin ]
On Wednesday, May 21, 2003, at 07:37 PM, Stas Bekman wrote:
> David, the latest wind is not to do anything at all with Apache-Test.
>
> Instead replace Apache/test.pm with Apache/testold.pm in the mod_perl
> distro and ask all those who use Apache::test (which should be very
> few) to re-release their packages using Apache::testold (and even
> better Apache::Test) or simply bundle Apache/test.pm in their t/ or
> inc/ subdirs (so it wouldn't get installed).
That's fine with me. You'll still have to have mod_perl 1.28 uninstall
the old test.pm, though. If you just change it to testold.pm in the
mod_perl distro, test.pm will be left alone unless it is uninstalled.
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
On Wednesday, May 21, 2003, at 07:37 PM, Stas Bekman wrote:
> David, the latest wind is not to do anything at all with Apache-Test.
>
> Instead replace Apache/test.pm with Apache/testold.pm in the mod_perl
> distro and ask all those who use Apache::test (which should be very
> few) to re-release their packages using Apache::testold (and even
> better Apache::Test) or simply bundle Apache/test.pm in their t/ or
> inc/ subdirs (so it wouldn't get installed).
That's fine with me. You'll still have to have mod_perl 1.28 uninstall
the old test.pm, though. If you just change it to testold.pm in the
mod_perl distro, test.pm will be left alone unless it is uninstalled.
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
David Wheeler wrote:
> On Monday, May 19, 2003, at 08:17 PM, Stas Bekman wrote:
>
>> 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.
>
>
> Why not? I mean, Apache/test.pm is something that you nominally control,
> right? And you're replacing it, right?
David, the latest wind is not to do anything at all with Apache-Test.
Instead replace Apache/test.pm with Apache/testold.pm in the mod_perl distro
and ask all those who use Apache::test (which should be very few) to
re-release their packages using Apache::testold (and even better Apache::Test)
or simply bundle Apache/test.pm in their t/ or inc/ subdirs (so it wouldn't
get installed).
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
David Wheeler wrote:
> On Monday, May 19, 2003, at 08:17 PM, Stas Bekman wrote:
>
>> 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.
>
>
> Why not? I mean, Apache/test.pm is something that you nominally control,
> right? And you're replacing it, right?
David, the latest wind is not to do anything at all with Apache-Test.
Instead replace Apache/test.pm with Apache/testold.pm in the mod_perl distro
and ask all those who use Apache::test (which should be very few) to
re-release their packages using Apache::testold (and even better Apache::Test)
or simply bundle Apache/test.pm in their t/ or inc/ subdirs (so it wouldn't
get installed).
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
On Monday, May 19, 2003, at 08:17 PM, Stas Bekman wrote:
> 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.
Why not? I mean, Apache/test.pm is something that you nominally
control, right? And you're replacing it, right?
Anyway, I applied your patch. It looks like it ought to work, but it
seems to be confused. Was it supposed to be applied over the last patch
you sent? I had to dump the changes that that patch had made to
Makefile.PL because your new patch failed. The new patch applied fine
to a fresh Makefile.PL in CVS, but it doesn't work:
mercury% perl Makefile.PL
Can't locate Apache/Test.pm in @INC (@INC contains: lib
/usr/local/bricolage/lib /Users/david/dev/perl/myco/classes
/usr/local/lib/perl5/5.8.0/darwin /usr/local/lib/perl5/5.8.0
/usr/local/lib/perl5/site_perl/5.8.0/darwin
/usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl .)
at lib/Apache/TestRequest.pm line 8.
BEGIN failed--compilation aborted at lib/Apache/TestRequest.pm line 8.
Compilation failed in require at lib/Apache/TestConfigPerl.pm line 10.
BEGIN failed--compilation aborted at lib/Apache/TestConfigPerl.pm line
10.
Compilation failed in require at lib/Apache/TestConfig.pm line 29.
BEGIN failed--compilation aborted at lib/Apache/TestConfig.pm line 29.
Compilation failed in require at lib/Apache/TestMM.pm line 7.
BEGIN failed--compilation aborted at lib/Apache/TestMM.pm line 7.
Compilation failed in require at Makefile.PL line 14.
BEGIN failed--compilation aborted at Makefile.PL line 14.
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
-- justin ]
On Monday, May 19, 2003, at 08:17 PM, Stas Bekman wrote:
> 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.
Why not? I mean, Apache/test.pm is something that you nominally
control, right? And you're replacing it, right?
Anyway, I applied your patch. It looks like it ought to work, but it
seems to be confused. Was it supposed to be applied over the last patch
you sent? I had to dump the changes that that patch had made to
Makefile.PL because your new patch failed. The new patch applied fine
to a fresh Makefile.PL in CVS, but it doesn't work:
mercury% perl Makefile.PL
Can't locate Apache/Test.pm in @INC (@INC contains: lib
/usr/local/bricolage/lib /Users/david/dev/perl/myco/classes
/usr/local/lib/perl5/5.8.0/darwin /usr/local/lib/perl5/5.8.0
/usr/local/lib/perl5/site_perl/5.8.0/darwin
/usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl .)
at lib/Apache/TestRequest.pm line 8.
BEGIN failed--compilation aborted at lib/Apache/TestRequest.pm line 8.
Compilation failed in require at lib/Apache/TestConfigPerl.pm line 10.
BEGIN failed--compilation aborted at lib/Apache/TestConfigPerl.pm line
10.
Compilation failed in require at lib/Apache/TestConfig.pm line 29.
BEGIN failed--compilation aborted at lib/Apache/TestConfig.pm line 29.
Compilation failed in require at lib/Apache/TestMM.pm line 7.
BEGIN failed--compilation aborted at lib/Apache/TestMM.pm line 7.
Compilation failed in require at Makefile.PL line 14.
BEGIN failed--compilation aborted at Makefile.PL line 14.
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 -0000 1.8
+++ Apache-Test/Makefile.PL 20 May 2003 03:13:56 -0000
@@ -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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 -0000 1.8
+++ Apache-Test/Makefile.PL 20 May 2003 03:13:56 -0000
@@ -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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
-- justin ]
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.
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
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.
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
>> 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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
>> 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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
On Monday, May 19, 2003, at 07:40 PM, Stas Bekman wrote:
> 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.
Good point.
> 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.
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
-- justin ]
On Monday, May 19, 2003, at 07:40 PM, Stas Bekman wrote:
> 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.
Good point.
> 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.
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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<use
> 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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 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
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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<use
> 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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
-- justin ]
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
> 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?
> 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<use
lib> unshifts directory names onto the front of @INC, in most cases it
should just continue to work.
At any rate, you'll still have the problem of users installing mod_perl
1.27 after installing Apache::Test.
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
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
> 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?
> 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<use
lib> unshifts directory names onto the front of @INC, in most cases it
should just continue to work.
At any rate, you'll still have the problem of users installing mod_perl
1.27 after installing Apache::Test.
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
-- 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
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
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
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
-- 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
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
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
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
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
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
[ This message is resent on behalf of David Wheeler <da...@wheeler.net>.
-- 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
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
[ This message is resent on behalf of David Wheeler <da...@wheeler.net>.
-- justin ]
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. 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.
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
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. 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.
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
David Wheeler wrote:
> 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.
so that bug should be fixed in CPANPLUS, in any case new Apache/test will have
a $VERSION
>> 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.
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.
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;
---------------------
these two wrappers (the are a part of the attached patch) will live together
in Apache-Test, on case-sensitive systems they will both installed and will do
the right thing. On case-insensitive only one will win, but nevertheless it'll
work regardless of 'require Apache::Test' or 'require Apache::test', since any
file will load both package.
I also had to add a workaround for $VERSION settings. So
perl -MExtUtils::MakeMaker -le 'print MM->parse_version(shift)' Apache/test.pm
perl -MExtUtils::MakeMaker -le 'print MM->parse_version(shift)' Apache/Test.pm
will do the right thing.
See if you can spot some problems with that solution. And also give it a try.
For mod_perl 1.0, we are simply going to nuke Apache/test.pm from there and
replace it with full Apache-Test cvs repository, so we need to apply any
changes to Apache/test_mp1.pm it'll be only under one source control.
Let me know what do you think.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
David Wheeler wrote:
> 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.
so that bug should be fixed in CPANPLUS, in any case new Apache/test will have
a $VERSION
>> 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.
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.
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;
---------------------
these two wrappers (the are a part of the attached patch) will live together
in Apache-Test, on case-sensitive systems they will both installed and will do
the right thing. On case-insensitive only one will win, but nevertheless it'll
work regardless of 'require Apache::Test' or 'require Apache::test', since any
file will load both package.
I also had to add a workaround for $VERSION settings. So
perl -MExtUtils::MakeMaker -le 'print MM->parse_version(shift)' Apache/test.pm
perl -MExtUtils::MakeMaker -le 'print MM->parse_version(shift)' Apache/Test.pm
will do the right thing.
See if you can spot some problems with that solution. And also give it a try.
For mod_perl 1.0, we are simply going to nuke Apache/test.pm from there and
replace it with full Apache-Test cvs repository, so we need to apply any
changes to Apache/test_mp1.pm it'll be only under one source control.
Let me know what do you think.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
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
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
[ This message is resent on behalf of David Wheeler <da...@wheeler.net>.
-- 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
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
[ This message is resent on behalf of David Wheeler <da...@wheeler.net>.
-- justin ]
On Tuesday, May 13, 2003, at 03:50 PM, Stas Bekman wrote:
> 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.
Okay, good. I felt that was a better long-term solution, anyway.
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
On Tuesday, May 13, 2003, at 03:50 PM, Stas Bekman wrote:
> 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.
Okay, good. I felt that was a better long-term solution, anyway.
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
-- 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
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
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
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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.
--
best regards,
randy
Re: resolving Apache::Test vs. Apache::test collision
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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.
--
best regards,
randy
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
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
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
-- 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
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
[ This message is resent on behalf of David Wheeler <da...@wheeler.net>.
-- 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
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
[ This message is resent on behalf of David Wheeler <da...@wheeler.net>.
-- justin ]
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.
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
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.
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 5 May 2003, Geoffrey Young wrote:
> 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 :)
On Win32, at least, installing Apache::Test will clobber
Apache::test, but, from what I've experienced, it will
copy the Apache/Test.pm from blib/ to the system Apache/test.pm.
So one ends up with an Apache::test that is actually
Apache::Test. And vice versa - if you install, on a fresh
system, Apache::Test, so that you have a system Apache/Test.pm,
and then install Apache::test from mod_perl 1, you'll end
up with an Apache::Test that is actually Apache::test.
This isn't a Perl thing - from a DOS window, suppose
one has
C:\test.txt
C:\tmp\tESt.txt
Then doing a
C:\> copy C:\temp\tESt.txt C:\
will result in C:\test.txt (actually being C:\tmp\tESt.txt).
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.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
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.
> 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
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
[ This message is resent on behalf of David Wheeler <da...@wheeler.net>.
-- justin ]
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.
> 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
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 5 May 2003, Geoffrey Young wrote:
> 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 :)
On Win32, at least, installing Apache::Test will clobber
Apache::test, but, from what I've experienced, it will
copy the Apache/Test.pm from blib/ to the system Apache/test.pm.
So one ends up with an Apache::test that is actually
Apache::Test. And vice versa - if you install, on a fresh
system, Apache::Test, so that you have a system Apache/Test.pm,
and then install Apache::test from mod_perl 1, you'll end
up with an Apache::Test that is actually Apache::test.
This isn't a Perl thing - from a DOS window, suppose
one has
C:\test.txt
C:\tmp\tESt.txt
Then doing a
C:\> copy C:\temp\tESt.txt C:\
will result in C:\test.txt (actually being C:\tmp\tESt.txt).
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.
--
best regards,
randy
Re: resolving Apache::Test vs. Apache::test collision
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
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
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>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).
>>
>>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'.
>
>
> I like using the idea of using/reserving Test::Apache here. Why not combine
> options 1 & 2 by making Test::Apache the package loader for Apache::Test
> (ie, instead of Apache::TestLoad)? That way, 3rd party modules that
> have problems with Apache::test can use Test::Apache, and httpd-test
> development can continue within the Apache::Test namespace.
The problem is that *all* 3rd party modules which use/plan to use Apache::Test
have this problem. They might not be aware of it, because they either aren't
running WinFU/OSX or they don't have mp1 installed.
> 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.
That has the same problem as s/Apache::Test/Apache::TestLoad/, you load one
package but use the other.
As of this moment I think the best solution is to extend Apache::Test to
support Apache::test and make sure that the installed Apache/test.pm is
removed/replaced. The only drawback with this approach (other than the need to
code it) is that if someone installs an older mp1 after installing
Apache::Test they will install Apache/test.pm. I assume that the next version
of mp1 will be aware of Apache::Test.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>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).
>>
>>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'.
>
>
> I like using the idea of using/reserving Test::Apache here. Why not combine
> options 1 & 2 by making Test::Apache the package loader for Apache::Test
> (ie, instead of Apache::TestLoad)? That way, 3rd party modules that
> have problems with Apache::test can use Test::Apache, and httpd-test
> development can continue within the Apache::Test namespace.
The problem is that *all* 3rd party modules which use/plan to use Apache::Test
have this problem. They might not be aware of it, because they either aren't
running WinFU/OSX or they don't have mp1 installed.
> 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.
That has the same problem as s/Apache::Test/Apache::TestLoad/, you load one
package but use the other.
As of this moment I think the best solution is to extend Apache::Test to
support Apache::test and make sure that the installed Apache/test.pm is
removed/replaced. The only drawback with this approach (other than the need to
code it) is that if someone installs an older mp1 after installing
Apache::Test they will install Apache/test.pm. I assume that the next version
of mp1 will be aware of Apache::Test.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
[ This message is resent on behalf of David Wheeler <da...@wheeler.net>.
-- 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
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
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
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
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.
EU::MM pros invited to comment.
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by David Wheeler <da...@wheeler.net>.
[ This message is resent on behalf of David Wheeler <da...@wheeler.net>.
-- justin ]
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.
EU::MM pros invited to comment.
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: resolving Apache::Test vs. Apache::test collision
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> 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).
>
> 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'.
I like using the idea of using/reserving Test::Apache here. Why not combine
options 1 & 2 by making Test::Apache the package loader for Apache::Test
(ie, instead of Apache::TestLoad)? That way, 3rd party modules that
have problems with Apache::test can use Test::Apache, and httpd-test
development can continue within the Apache::Test namespace.
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.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: resolving Apache::Test vs. Apache::test collision
Posted by James G Smith <JG...@TAMU.Edu>.
[ This message is resent on behalf of James G Smith <JG...@TAMU.Edu>.
-- justin ]
Stas Bekman <st...@stason.org> 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 <JG...@TAMU.Edu>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix
Re: resolving Apache::Test vs. Apache::test collision
Posted by Joe Schaefer <jo...@sunstarsys.com>.
[ This message is resent on behalf of Joe Schaefer
<jo...@sunstarsys.com>. -- justin ]
Stas Bekman <st...@stason.org> writes:
> 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).
>
> 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'.
I like using the idea of using/reserving Test::Apache here. Why not combine
options 1 & 2 by making Test::Apache the package loader for Apache::Test
(ie, instead of Apache::TestLoad)? That way, 3rd party modules that
have problems with Apache::test can use Test::Apache, and httpd-test
development can continue within the Apache::Test namespace.
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.
--
Joe Schaefer